-- Саша Стаменковић <umpir...@gmail.com> wrote
(on Thursday, 30 July 2009, 03:59 PM +0200):
> Hm, will it be possible to set autoloader like now, and don't need to mess
> around with namespace and require (use) statements?
The namespace and use statements are not the same as require_once.
"namespace" is used to denote what namespace the current code exists in.
The class name within the file resolves to a combination of
namespace\classname.
"use" and "import" are statements that are used to bring other
namespaces into the local scope so that you can qualify classes from
other namespaces easily. In point of fact, if you *don't* have
autoloading, you would need to also supply require_once statements for
classes within the namespaces they reference if you use them in your
code!
So, the short summary is: the autoloader has nothing to do with usage of
the "namespace" and "import/use" statements -- but has everything to do
with how classes within the current namespace or aliased namespaces are
resolved. Once we have refactored to use namespaces, we will also be
shipping an autoloader that resolves classes contained in namespaces.
> 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/
>
>
--
Matthew Weier O'Phinney
Project Lead | matt...@zend.com
Zend Framework | http://framework.zend.com/
