> Here are a few more examples of renaming the top-level class/sub-class > names: > > Zend_Acl_Role => Zend_Acl_Role_Role > Zend_Acl_Resource => Zend_Acl_Resource_Resource > Zend_Cache => Zend_Cache_Cache > Zend_Cache_Backend => Zend_Cache_Cache_Backend_Backend > Zend_Db => Zend_Db_Db > Zend_Db_Profiler => Zend_Db_Profiler_Profiler > > [...]
This isn't intuitive or desirable in my view. While modularization has always been a positive aspect of Zend Framework (the ability to just use Zend_Mail in your application, for example), it doesn't mean each component is standalone. Zend_Mail depends on Zend_Mime, Zend_Exception, and maybe some other things. Upgrading just Zend_Mail might break your application if you fail to account for the other dependencies. Packaging it in this way has a very small benefit for a single use case (svn:externals) at the expense of a much less intuitive API. I mean, even you were tripped up by Zend_Cache_Backend_Backend. Plus, class names are long enough already. If loadClass() were revamped to accomodate this alternate file scheme and the class names were kept the same (i.e., Zend_Cache_Backend refers to Zend/Cache/Backend/Backend.php), that is even worse. -Matt
