I also find Zend.php a bit of an odd mix of methods that could well be superseded by more specific classes like Zend_Registry. If you look at its methods...

loadClass
loadInterface
loadFile
isReadable
dump
register
registry
isRegistered

...and you take out the last 3 as repeating what a registry class would include. Then move the first 3-4 into a loader class that basically leaves one method that simply prettifies var_dump. On that basis I think Zend.php would be better off replaced by more focussed classes like Zend_Registry, Zend_Loader and Zend_Debug.

On my initial use of the class I did expect it to grow with the framework perhaps to include the kind of methods that Simon mentioned...

Zend::setPath($id, $path) / Zend::getPath($id)

...however they themselves may well be the subject of other classes (Zend_Pathfinder?) and if Zend.php was to include them it would become increasingly difficult to define exactly what the Zend object was and what it should or should not include.

My vote is dump it ...I think!

Nick

Simon Mundy wrote:
Except that it is not for the framework to use -- it is for userland and separate specific classes would be better to use for that.

I disagree - Zend.php should be used as part of the coding standards for the sake of consistency and reusability.

A lot of the components use 'require_once' which would be better replaced with Zend::load(). Say - for example - in the distant future it was decided that the PEAR standard of underscores replacing directory separators was not such a good idea and a new scheme was chosen. We'd have to completely pull apart the framework to replace hardcoded require_once() calls with the new paths. But if we use Zend::load('Class') then there's only 1 place it needs updating. To my mind it follows the DRY principle very well and helps to create more readable, reliable code.
I agree with the premise, but I fail to see how Zend_Loader::load ('Class') or Zend_Registry::getInstanceOf('Class', $args) would not do the same thing, but be a better separation of concerns.


Reply via email to