I just did a quick survey to see what in Zend.php is used within the
framework. I note that Zend_Cache chose not to use Zend::loadClass. And
the controller code, which was the original user of this code, should
probably have its own special purpose loader. In general, nothing in
Zend.php is really needed. The more I look into this the less I like it.
Zend::registry() is only used in:
- Zend_Db_Table (I won't even go into why)
Zend::loadClass() is used in:
- Zend_Getopt (only to load Zend_Json within function toJson())
- Zend_Controller_Front (this is the main use for it)
- Zend_Db (only for that darn factory)
- Zend_Main_Transport_Smtp
- Zend_Session (only to load optional validators)
Zend::isReadable() is used in:
- Zend_Controller_Dispatcher_Standard
- Zend_View_Abstract
Zend::exception() is not used.
Zend::register() is not used.
Zend::isRegistered() is not used.
Zend::initRegistry() is not used.
Zend::dump() is not used.
Zend::compareVersion() is not used.
Gavin Vess wrote:
Matthew Ratzloff wrote:
The existing one [Zend_Registry] works perfectly well.
It uses __set() and __get(), and implements ArrayObject.
Thank you :) .. there was an amazing amount of debate over this for months,
before the current solution became accepted. I vastly prefer the new
Zend_Registry to the old ZF 0.2 approach.
Ralf Eggert wrote:
"because I only need to load and use the stuff I really want to use".
If someone does not want to use the Zend_Registry why forcing him to
load it on each request?
Andries nicely summarized many recent community contributions:
http://framework.zend.com/wiki/x/j1
One of the key concerns in the proposal relates to how we might add
important and valuable additional features and functionality to
"utility" functions in the ZF, without rewriting existing code. See
Zend::initRegistry() for an example solution to this type of problem.
By "utility", I mean things like the debug function, compareVersion, and
file/class utilities, such as the additions proposed by Aleksky:
http://framework.zend.com/wiki/x/4Uo
Reliance on static methods limits available solutions. Some of you have
made a case that Zend_Registry fits the description, "valuable, but not
really required to be loaded for all ZF apps, including hello-world
apps." The current static API for the registry uses a feather-weight
Zend_Registry class, with the old static methods in Zend.php existing to
preserve backwards compatibility, and to dynamically load the real
Zend_Registry, only if it is actually used. The static methods also
show one way to combine a static API to load a "normal" class on-demand,
without using autoload or forcing the loading of the "normal" class in
all ZF apps. The Zend::initRegistry() and proxy code in Zend.php
currently also allows developers to create a subclass, and have existing
code use their subclass via simple dependency injection.
Unfortunately, all the registry code in Zend.php totals 52 lines,
excluding comments and empty lines. Moving all this registry code from
Zend.php to Zend_Registry might address some of the concerns voiced
recently in this thread (relating to the registry), although that would
add one line of code (require) to a ZF bootstrap for those not using
autoload.
Rob Allen wrote:
I don't see the registry as core functionality unless another component
relies on it?
See http://framework.zend.com/wiki/x/Sks
However, this proposed component uses a private instance of Zend_Registry.
I am not currently expecting any core components to ever directly use
the old static interface in Zend.php that proxies to Zend_Registry.
Also we already have a Zend/Registry.php containing Zend_Registry. If a
static interface is required for the registry, then we may as well just
add it to the current class.
If we are ok with adding one require statement to our bootstraps, then I
have a hard time finding reasons to disagree.
it really isn't a big deal to keep it for convenience
class Zend_Debug {
static public function dump($var, $label=null, $echo=true)
}
// Could live with the following outside of Core.php but it's so small
Definitely not core. This will limit our ability to put in a more "fully
featured" Zend/Debug.php at a later date. Better to do that now and put
this class in its own file.
My personal preference is to preserve the ability for developers to
overload Zend_Registry, if desired, without rewriting existing code
using the current registry. I can see multiple ways to provide this
flexibility, including the current SVN code, and something similar with
the "registry" code from Zend.php merged into the existing
Registry.php. However, we have a very narrow window of time remaining,
before API changes become much more difficult.
Cheers,
Gavin
