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
