Ok, I have been going through the paces learning Zend Framework and the
pieces involved, and sometime it seems like design patterns are used when
they end up just creating lots of overhead, for zero gain.
Consider the Zend_Registry class, and the registry design pattern it is
implementing. For starters, accessing methods in the registry class is not
exactly free. There is a lot of overhead involved in getting into the
registry class and finding the information needed, way more overhead than
just accessing a global variable.
Now, I am sure we all agree that global variables are a bad thing,
especially global variables that are accessible everywhere. To me, that is
what the registry design pattern is intended to solve, but PHP does NOT have
this problem. Global variables in PHP are only accessible from code running
in the global space, not from within functions or from within methods. At
least not unless you specifically declare a variable as Oglobal¹. So once
you are inside a function, or inside a class method, none of the globals in
the global space are actually in scope, so it is not possible to
accidentally change the globals or use them out of context (which is the
danger of globals in languages like C and C++).
In all our PHP code we prefer to use the $GLOBALS super global to access
global variables, rather than using the global declaration, as it makes it
clear you are accessing a global variable. So we would use this:
function set_global()
{
$GLOBALS['my_global'] = 'fun_stuff';
}
function use_global()
{
$use_global = $GLOBALS['my_global'];
}
rather than this:
function set_global()
{
global $my_global;
$my_global = 'fun_stuff';
}
function use_global()
{
global $my_global;
$use_global = $my_global;
}
Now. In both of these cases, the global variables are NOT by default in the
scope of the function that uses them, and in the context of a framework like
Zend Framework, nothing runs in the global space anyway, except the very
first index.php file that boostraps everything.
So, according to the Registry design pattern modeled by Zend_Registry, we
should do this instead:
function set_global()
{
$my_global = Zend_Registry::set('my_global','fun_stuff');
}
function use_global()
{
$use_global = Zend_Registry::get('my_global');
}
Now clearly this is not all that much different to my first example above
that uses the super global $GLOBALS. In fact, using the $GLOBALS variable is
less typing, just as clear and more importantly, has ZERO overhead to using
it. Unlike the Zend_Registry::get() function that executes quite a lot of
code just to get a global variable.
So after examining this some more, it seems to me both a waste of typing and
waste of CPU resources to use the Zend_Registry class, when you can just as
easily reach for the $GLOBALS super global variable for the very few
instances where you do need access to global information.
Regards,
Kendall Bennett, CEO
A Main Hobbies
424 Otterson Drive, Suite 160
Chico, CA 95928
1-800-705-2215 (Toll-Free)
1-530-894-0797 (Int'l & Local)
1-530-894-9049 (Fax)
http://www.amainhobbies.com
