Zend_Registry useless?

tangfucius · #1 (**permalink**) 04-16-2008, 05:58 AM

According to this article: PHPit - Totally PHP Using globals in PHP
Global variables have the following problems:

1. Reusing parts of the script is impossible
If a certain function relies on global variables, it becomes almost impossible to use that function in a different context. Another problem is that you can’t take that function, and use it in another script.

2. Solving bugs is much harder
Tracking a global variable is much harder than a non-global variable. A global variable could be declared in some obscure include file, which could take hours to find, although a good text editor / IDE could help with this.

3. Understanding the code in a year will be much more difficult
Globals make it difficult to see where a variable is coming from and what it does. You might know about every global during development, but after a year or so you’ll probably have forgotten at least half of them, and then you’ll be kicking yourself for using so many globals.

Then the author proposes Registry as the eventual solution to global variables… But I really don’t see how the Registry pattern really solves the above 3 problems. You still can’t reuse part of the code if the objects aren’t created and stored in the Registry first, just like the global variables have to be created first. You still will run into bugs if you don’t take care of your Registry well. You still will find the code difficult to understand if you don’t remember where you are processing your Registry. None of the problems caused by global variables is really solved here, Registry Pattern is fundamentally identical to global variables, and it really seems the “improvement” is more so the mental perception than actuality.

I'm posting it here so people who are knowledgeable can perhaps shine some light on solid reasons that Registry Pattern is actually as good as people say it is?

Ron · #2 (**permalink**) 04-16-2008, 11:49 AM

In my opinion zend_registry is for persisting information between instances of the script running. Like for storing database connection info, constant data that will not change during the course of the script running.

tangfucius · #3 (**permalink**) 04-16-2008, 02:40 PM

Ron,

PHP within itself is per request based and not multi-threaded like java or other things. Zend_Registry in no way enables you to share data across multiple separated scripts(unless you are talking about includes, but it doesn't seem that way). The only way to persist data in PHP is to store information in a database, and Zend_Registry isn't the answer here...

I've written more on this subject, Tangfucius

If I can find good answers, it really would be great.

Ron · #4 (**permalink**) 04-16-2008, 11:52 PM

Sorry, I didn't say that right. I was just referring to using it with an ini file, like an include. As I am a newbie to php I jumped in over my head. I think I will regress and stick to lurking. Since I did post I will add my two cents, It looks like zend_registry is just an alternative to using global variables, but it is just that, an alternative. It allows you to keep your global data in a class that has the scope of a global. Maybe that is what the article is suggesting. In any event I know I am going to learn something of interest here.... back to lurking!

Elemental · #5 (**permalink**) 04-17-2008, 02:41 PM

Quote:

<_elemental> JDempster: well I've been trying to find some sort of explanation for how Registry solves some of the issues with Globals and why its a preferred method of dealing with global scope variables/objects. Most of what I have found has discussed that globals are bad and cause issues with...
<_elemental> code reuse and the like, but I don't see how the Registry solves this..

<JDempster> _elemental: variables made outside of functions and methods automatically use global space, sometimes there's a need for something to be global, to actually put it there though Zend_Registry is probably a better idea

<_elemental> JDempster: but why is it better to use the registry?

<ue> _elemental, becouse global variables are harder to manage

<JDempster> _elemental: for me, it's the actual action required to put it in the registry that makes it easier to use

<vi390> _elemental: clear, easy, objectorientated, getter setter, persistant namespace, and other Developer come around with it better

<_elemental> Ok I understand in theory how this helps. It makes the management and use easier to deal with in your head, but is there a code level reason? [I mean] how does using the registry to hold all of your globals help with reuse, debugging and understanding the code a year from now?

<_elemental> you still have to track down where the objects were set in the registry, like you have to track down where a global was declared...
you still have to ensure the object is in registry before you can grab it so reuse is still an issue

<JDempster> traking down where somthing is decleared globally is much harder todo than though a registry
you can implmenet lazy loading though the registry

<_elemental> so would it be against best practice to say load up a custom registry with default configurations for objects you tend to store there?
if you try to call something that isn't there the registry makes the default object?

<vi390> _elemental: its ONE place instead of many, and its sort of "best practice", If you need something you just get it from there, well its sort of a similar thing like Global, but you have better error management (IIRC is there an exeption thrown if you try to get an unset value, if you use global Variables it would just magicaly NOT WORK)

<JDempster> personally I think thats fine, extends the registry object, instance it, overload the __get to check that said object exists if not load default e.g. log or db connection what ever

<_elemental> I see to the whole point of the registry is just better management of the global space

<ue> _elemental, from a 2 year old php4 project (no oop) : global $_mysql,$_configs,$_module,$_tpl,$_var,$_tpl_index ,$_now,$_info,$_lang,$_lang_data, $_keywords, $_title; ... you want your code look like this

?

<Ezku_> _elemental: a registry + factory combination would be called a service locator, if i'm not mistaken

<vi390> ue: good point ;-)

<Ezku_> _elemental: and yes, it would indeed be good practice.

<_elemental> ue: ok, but how is that any better than $registry->set(...); $registry->set(..); .....

<vi390> or $_GLOBAL[][][][][][]

<ue> _elemental, the most simple is, you don't need to redecalre this globals in every class, just call registery

<vi390> _elemental: it definately makes the code more readable

<ue> _elemental, there also many other "tasty" things that registery pattern gives you, some of them already pointed out

<vi390> _elemental: maybe you find the advantages of using a registry in suing it for a while

<_elemental> ok so Registry gives you better managment of the global space, more readable code, the option to add validation and factory patterns to the global space and enhanced maintainability, anything else?

<vi390> _elemental: registries are sexy

* _elemental likes sexy
<JDempster> lol well theres the best reason then
<_elemental> :P

design:the_registry [phpPatterns]
Registry - Patterns For PHP
PHPit - Totally PHP Using globals in PHP

tangfucius · #6 (**permalink**) 04-17-2008, 06:41 PM

thanks, that's one of the better explanations I've seen, and I've posted it at my blog. Tangfucius

SirAdrian · #7 (**permalink**) 04-21-2008, 10:32 PM

I think one of the key differences is you can programmatically track any changes to the data since it goes through set/get functions. You will also have less variables, so you can view the data as whole much better than the entire $GLOBALS array.

It also has a more semantic meaning - you are getting and setting data from the registry which is common data accross your application.

Generally with globals, they are part of the bulk of the script (procedural), but with this, it's a much smaller, which means much less (probably nil unless you are being stupid) chance of collision, which is the real risk with globals.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode