2009/5/3 Mr. Eric Eugene Naujock <naujo...@mac-cafe.com>:
> 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.
I have to agree, a lot of people seem to be obsessed with performance
on the micro scale, at the end of the day in the modern world hardware
is cheap and developers time is expensive, standardization for
developers enables us to easily understand and communicate within our
code. I would rather buy more memory/extra server etc than waste time
trying to shave a couple of milliseconds off, I know this may become a
problem if you work for Google or twitter etc but most of us don't
require such minute optimizations.
>
> 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 <christopher.oestl...@gmail.com>
>> Date: Sat, 2 May 2009 15:01:01 -0700
>> Cc: Zend Framework General <fw-general@lists.zend.com>
>> 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
>> <kenda...@amainhobbies.com>
>> 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
>>>
>>
>>
>>
>>
>
>
--
----------------------------------------------------------------------
[MuTe]
----------------------------------------------------------------------
