Oops! I agree - the code in Zend.php could be split up into specialized components and obsolete code could be eliminated. I just over-looked the earlier discussions on this thread while posting my message.
On 2/27/07, Matthew Ratzloff <[EMAIL PROTECTED]> wrote:
> For what it's worth, it is ideal to retain the Zend.php instead of > splitting it up so the framework could build more utility functions into > it in future - that does not fit anywhere. How about renaming it to > Zend_Util, instead? I can't imagine any utility methods that would be needed that could not be put into a more full-fledged class. Looking at the existing methods: Zend::loadClass() => Zend_FileSystem::loadClass() Zend_FileSystem could include recursive directory iterators, regular expressions-based file manipulation, etc. Zend::dump() => Zend_Debug::dump() Zend_Debug could include a whole host of additional debugging information, interaction with Zend_Log for trace messages, pseudo-breakpoints, etc. And Zend_Registry already exists. With a separate Zend_Registry class, it's possible to have customized registries for different parts of large applications--providing a scaled-down version of the registry for plug-in developers, for instance. Passing it as an object through the controller's setParam() method also makes it easier to test, say, individual actions. In all cases, the framework benefits from individual, specialized components. If we keep Zend.php (or whatever it would become), I think it'll be there forever. If it were removed at some point in the future, it would really slow adoption of whatever version removed it. People will have Zend::register() or Zend::loadClass() calls throughout their applications and be sluggish to invest the time in changing them. It's like PHP deciding to change array declaration to $array = [1, 2, 3] and deprecating (and eventually removing) the array() construct. They could never do it. -Matt
