Hm, will it be possible to set autoloader like now, and don't need to mess
around with namespace and require (use) statements?
Regards,
Saša Stamenković
On Thu, Jul 30, 2009 at 3:41 PM, Matthew Weier O'Phinney
<matt...@zend.com>wrote:
> -- Jens Ljungblad <jens.ljungb...@tjoff.com> wrote
> (on Thursday, 30 July 2009, 05:19 AM -0700):
> > I have a few question about what the naming scheme will look like now
> that
> > Php 5.3 and namespaces is here. I've looked a bit at Zend_Application and
> > how that component is structured.
> >
> > 1. Should all base level classes be moved? So that for instance, a class
> > such as Zend_View should instead be called Zend_View_View?
> >
> > 2. Should it be Zend_Db_Table_Row_RowAbstract or
> Zend_Db_Table_RowAbstract?
> > When is it appropriate to create subfolders, or "subpackages"?
> >
> > 3. When there is an abstract class, but no real need for a concrete one,
> > should an empty conrete class exist anyway? For instance, should there
> > be an empty Zend_Db_Table_Row extending Zend_Db_Table_RowAbstract?
> > Currently this seems to be the case in some instances. Is this only to
> > make the class name shorter?
> >
> > Just curious so I know how to best structure my own library!
>
> The guidelines for abstract classes and interfaces will be included in
> the manual with ZF 1.9.0 (and you can grab the docs for RC1 and see
> these). Basically, the rules are:
>
> * Abstract classes are suffixed with the word "Abstract", with no
> preceding "_": Zend_Foo_BarAbstract
>
> * Interfaces are suffixed with the word "Interface", with no preceding
> "_": Zend_Foo_BarInterface
>
> Regarding question 3, we often provide abstract classes with empty or
> nearly empty concrete implementations. This allows us to typehint on the
> abstract implementation or interface, while still offering something
> that's fully useable. However, in the specific example cited,
> Zend_Db_Table_Row actually existed before Zend_Db_Table_Row_Abstract,
> and was refactored later to have an abstract implementation.
>
> Regarding subcomponents, if they represent a true subcomponent -- i.e.,
> typically, you answer "yes" to the the question "will there be concrete
> instances of it?" -- then you will define the interface and/or abstract
> representations in that namespace:
>
> Zend_Db_Table_TableInterface
> Zend_Db_Table_TableAbstract
>
> When we adopt namespaces, these will become:
>
> \Zend\Db\Table\TableInterface
> \Zend\Db\Table\TableAbstract
>
> and be defined like this:
>
> namespace \Zend\Db\Table;
>
> interface TableInterface {}
> abstract class TableAbstract {}
>
> Which means that, for your own code that uses it, you can do this:
>
> namespace \My\Db\Table;
> use \Zend\Db\Table as Zdt;
>
> class Users extends Zdt\TableAbstract {}
>
> This is some time off, though; 2.0 will be the first time we have the
> opportunity to break BC, and adding namespace support is one of those
> times where we will need to do so. I've begun some rudimentary planning,
> which I will be sharing in the coming weeks and months, and we will
> hopefully have a roadmap sometime this fall. That said, we cannot really
> release 2.0 until we have a quorum of distributions that are shipping
> 5.3.x; until then, we'd be doing a disservice to our users.
>
> --
> Matthew Weier O'Phinney
> Project Lead | matt...@zend.com
> Zend Framework | http://framework.zend.com/
>
