OK I have been following this thread for a bit and while and I can see
some of the arguments made and is some cases may even be valid.
I have been only developing a short while with PHP and I remember
seeing this design pattern and structure you are promoting before. I
believe it was in a library called PHPLib. This was a wonderful
library back in the PHP3 days and even some of the early PHP4 days.
But then as time moved on things changed. PHP changed and many of the
GLOBALS and GLOBALS structures changed or their names changed.
Unfortunately as a result code that was rock solid under PHP3 started
to fail after PHP 4.1.x and under PHP5 it just started to seriously
fall apart, even with people patching and hacking the code to make it
work.
My question is this. Can you safely assume that the code you have
written that looks like it will work under PHP4. Works under PHP5,
will continue to work under PHP6 as you have designed it? While it may
be safe to say that you will just not upgrade your clients to PHP6 or
later and will deal with that at another time can you be sure you will
be the one doing the work then? Will you still be doing the work in 20
years when the code has to be worked on to keep it running? I use the
Zend framework for the several reasons. Though it may not be the
fastest it will be engineered beneath the surface and maintained in
such a way that the person maintaining my code in 10 years will easily
be able to do it. I will also be able to assume that be following the
design models outlines in the Zend Framework will continue to run well
and behave as expected under PHP6, PHP7 and PHP8.
Beyond that the fact that the Class you point to as an example of
inefficient code is also an example of foundational code. If it gets
flakey then everything built upon it gets flakey. I would rather have
rock solid code written to withstand the changes of time, rather then
something that depends on a structure that may well disappear in the
future.
In addition I have found that when profiling my code I find that no
matter how many operations I try to optimize as soon as I execute 1
SQL operation my code slows down dramatically. My bottlenecks are not
in the framework they tend to be in the database and the queries sent
to the database. Not that I try to write slow code.
But these are just my own 2 cents and you may take it or leave it.
Eric Naujock
On May 2, 2009, at 6:56 PM, Kendall Bennett wrote:
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
