Sure, but I still fail to see how Zend_Registry makes development any
faster? It is just a glorified version of the $GLOBALS super global, and if
you look at the meat of it, it is syntactically similar to using the
$GLOBALS super global.
$my_var = Zend_Registry::get('my_global');
and
$my_var = $GLOBALS['my_global'];
Are really not very different. Except one takes a WHOLE lot more CPU cycles
at runtime.
My point is that PHP has already mostly solved the global variable problem
by making it such that globals are NOT by default a part of the normal
variable scope when inside functions and class methods.
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
From: Christopher Östlund <[email protected]>
Date: Sat, 2 May 2009 15:01:01 -0700
Cc: Zend Framework General <[email protected]>
Subject: Re: [fw-general] Zend_Registry a waste of CPU resources?
There is a lot of overhead in using a framework, with the gain of fast
development.
On Sat, May 2, 2009 at 10:34 PM, Kendall Bennett <[email protected]>
wrote:
> 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
>
