Re: [fw-general] How will the naming scheme look with Php 5.3 namespaces?
Just to make sure I understood everything correctly:
1. In theory, base level classes should be moved inside their respective
package.
2. Classes within a package that can have concrete instances and has their
own interfaces and abstract classes belong in their own "subpackage". So for
instance: Zend_Db_Table_TableAbstract, Zend_Db_Table_Row_RowAbstract and
Zend_Db_Table_Rowset_RowsetAbstract.
3. There should be no completely empty concrete classes if there can be no
concrete instances of that class. If there are any such classes in the
framework at the moment, it is for backward compatibility reasons. (I
realize now that Zend_Db_Table_Row is not of them, since you can actually
create such an object and pass it config data)
Matthew Weier O'Phinney-3 wrote:
>
> -- Jens Ljungblad 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/
>
>
--
View this message in context:
http://www.nabble.com/How-will-the-naming-scheme-look-with-Php-5.3-namespaces--tp24737377p24746144.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] How will the naming scheme look with Php 5.3 namespaces?
-- Саша Стаменковић 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
> wrote:
>
> -- Jens Ljungblad 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/
Re: [fw-general] How will the naming scheme look with Php 5.3 namespaces?
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
wrote:
> -- Jens Ljungblad 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/
>
Re: [fw-general] How will the naming scheme look with Php 5.3 namespaces?
-- Jens Ljungblad 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/
Re: [fw-general] How will the naming scheme look with Php 5.3 namespaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Hi, > > 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? That is not clear for the moment, but when, the class "Zend_View" would actually be named "View" within the namespace "Zend\View". > 2. Should it be Zend_Db_Table_Row_RowAbstract or Zend_Db_Table_RowAbstract? > When is it appropriate to create subfolders, or "subpackages"? The first one for namespaces (again, class will be RowAbstract in the namespace Zend\Db\Table\Row. > 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? This is currently just for backward compatibility. > Just curious so I know how to best structure my own library! ... : ___ _ ___ ___ ___ _ ___: : | \ /_\ / __| _ \ _ (_) \ : : | |) / _ \\__ \ _/ / | |) | : : |___/_/:\_\___/_| |_|_\_|___/ : ::: : Web: http://www.dasprids.de : : E-mail : m...@dasprids.de : : Jabber : jab...@dasprids.de : : ICQ: 105677955 : ::: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpxpYcACgkQ0HfT5Ws789CK0wCgl/isPDljkATHOfzaOwtLimAN kJ0AoI2i/aD8jcRNyNQQ2zpVdIuMPTe/ =LKNn -END PGP SIGNATURE-
