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.