> 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

Reply via email to