-- Kendall Bennett <kenda...@amainhobbies.com> wrote
(on Saturday, 02 May 2009, 01:34 PM -0700):
> 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.
This argument has been debated many times over the last couple of years.
Globals are problematic on many levels. Setting and accessing them from
within method calls (using the $GLOBALS superglobal) can even cause
issues in certain circumstances (I've blogged on this before).
Most importantly, however, globals -- even global registries --
introduce difficult to track dependencies into your applications, making
them more difficult to test and harder to maintain. If you make an
application you distribute, they make it difficult to integrate the
application into others in order to create a site.
Finally, justifying the practice of using globals over a registry
(global or otherwise) based on performance is micro-optimization at
best.
> 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.
--
Matthew Weier O'Phinney
Project Lead | matt...@zend.com
Zend Framework | http://framework.zend.com/
