-- Mary Nicole Hicks <[email protected]> wrote (on Wednesday, 03 June 2009, 01:35 AM -0700): > jasonistaken wrote: > > On 02/06/2009 11:49 PM, Mary Nicole Hicks wrote: > > > When I use Zend_Uri_Http::check($string) > > > Which Uses: Zend_Validate_Hostname > > > Which Uses: Zend_Validate_Abstract > > > Which Uses: Zend_Registry? > > > > > Well, the abstract validation class facilitates automatic error > > message translation, if you're using a translator. It simply checks > > a few common places to see if there is a translation instance > > registered; one of these being Zend_Registry. > > > > I agree it's somewhat unfortunate that there are these occasional > > registry lookups.... > > If ZF is looking for an item in the Zend_Registry, can't it first check that > the Zend_Registry class exists with class_exists('Zend_Registry', FALSE); ? > Obviously if the class does not exist then there would be no reason to cause > it be instantiated.
First off, Zend_Registry is never instantiated in these cases. A static lookup is performed. You're confusing instantiation with class loading, which are very different. Now, as to the why's behind the dependency: In order to perform localization tasks, classes that have locale and/or translation integration will check for default locale and/or translation adapters in the registry if no adapters are registered in the given instance. We opted for using the global registry as localization is a task that is usually application-wide, and it makes sense to use the same objects throughout the application. While I appreciate that you may not use this particular feature, Zend_Registry is a very lightweight class that offers only a few convenience features over ArrayObject, which it extends. The overhead of this class and its lookups is negligble, and stripping the dependency would do more harm than good. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/
