I didn't find any reasons given for changing the existing registry API
in Zend.php to the one in the proposal.
Does anyone else want or need a static setter/getter for Zend_Registry?
Static methods can not have the same names as public methods. The
"$this" variable is not set when invoking a static method on an instance
object. Combining Zend.php's static registry methods into Zend_Registry
requires the static getter/setter methods to remain inconsistent with
the names of the getter and setter methods for instance objects (as it
is now in Zend.php and Zend_Registry.php). However, nothing prevents us
from changing the names to something less confusing :)
For option C/E in the proposal, moving static setters/getters to a
subclass of Zend_Registry minimizes bloat in Zend_Registry.php.
However, this argument is weak, since the total bloat is very small.
What is simpler?
Current way in Zend.php / Zend_Registry.php:
====================================
$registry = Zend::registry();
$registry['key1'] = 'value1';
$registry['key2'] = 'value2';
Zend::register('key1') = 'value1';
Zend::register('key2') = 'value2';
New way in proposal:
====================================
$registry = Zend_Registry::getInstance();
$registry['key1'] = 'value1';
$registry['key2'] = 'value2';
Alternative new way:
====================================
Zend_Registry::set($key, $value);
Zedn_Registry::get($key);
With the above get(), the current instance method version of get() in
the proposal is replaced with a method that only works on the "global"
registry stored in the static class variable. Instance methods for
accessors remain the same as for ArrayObject (i.e. inherited as they are
now in Registry.php).
Cheers,
Gavin
Stanislav Malyshev wrote:
What if we included the subclass "in the box"?
Both the old and the new are designed to work smoothly with subclasses.
I'm not sure I understand why we would need two classes - why is it
better than having once class?
