Poll: 2.0 and Namespace impact of class names

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Poll: 2.0 and Namespace impact of class names

Ralph Schindler-2
Hey all-

One more to discuss for today ;)



On the Usage of Compound Names --

With namespaces, we have the opportunity to create aliases to specific
namespace our code consumes.  For example, we can do something like this:


<?php
// in a script that consumes Zend Frameowrk
use Zend\Filter as f;

$filter = new f\Something.php

?>


In the past, with fully prefixed names, it was easy to understand the
context of a particular class since the namespace is carried with it.
$filter = new Zend_Filter_Int(); is clearly an Integer filter, and the
class name fully reflects that.

The question with namespaces is, should we use compound names to
identify classes separate of the namespace itself.  This can be better
demonstrated with the following code:


<?php

use Zend\Filter as f;

$filter = new f\Int();

?>


-- VS --


<?php

use Zend\Filter as f;

$filter = new f\IntFilter();

?>


In the latter example, the original class name (without the prefix)
might have been Int, but this class name has been 'suffixed' with a term
that gives the class name more meaning.  (In english, this means that
the class name now has the adjective 'Int' and the noun 'Filter', or a
noun-noun combination).

Which is a better route to explore in your opinion? Which has more
meaning to you as a developer consuming ZF?

As a technical side-note, this might be required for some prefixed names
that reduce down into PHP reserved words, for example
Zend_CodeGenerator_Php_Class cannot become namespace
Zend\CodeGenerator\PHP class Class due to its restrictions on class naming.

Thoughts?
-ralph

Reply | Threaded
Open this post in threaded view
|

Re: Poll: 2.0 and Namespace impact of class names

Andy Thompson
Hi,

Suffixing the class name with its intent seems like the best way in my
opinion. In my own libraries, I've been frustrated with the way I might
have 3 or 4 of the same filenames open e.g. Field\DateTime.php,
Filter\DateTime.php, Validate\DateTime.php and Element\DateTime.php
(though that last one I've now renamed to DateTimeSelect).

In my IDE, and I'm sure a lot of others do this, this shows just the
filename DateTime.php. I've already started using suffixes in my PHP 5.3
code.

Also this frees us to not have to define our own whole Filter namespace
when a package is just not designed to supply filters.

Regards

Andy

On 16/03/2010 06:31, Ralph Schindler wrote:

> Hey all-
>
> One more to discuss for today ;)
>
>
>
> On the Usage of Compound Names --
>
> With namespaces, we have the opportunity to create aliases to specific
> namespace our code consumes.  For example, we can do something like this:
>
>
> <?php
> // in a script that consumes Zend Frameowrk
> use Zend\Filter as f;
>
> $filter = new f\Something.php
>
> ?>
>
>
> In the past, with fully prefixed names, it was easy to understand the
> context of a particular class since the namespace is carried with it.
> $filter = new Zend_Filter_Int(); is clearly an Integer filter, and the
> class name fully reflects that.
>
> The question with namespaces is, should we use compound names to
> identify classes separate of the namespace itself.  This can be better
> demonstrated with the following code:
>
>
> <?php
>
> use Zend\Filter as f;
>
> $filter = new f\Int();
>
> ?>
>
>
> -- VS --
>
>
> <?php
>
> use Zend\Filter as f;
>
> $filter = new f\IntFilter();
>
> ?>
>
>
> In the latter example, the original class name (without the prefix)
> might have been Int, but this class name has been 'suffixed' with a
> term that gives the class name more meaning.  (In english, this means
> that the class name now has the adjective 'Int' and the noun 'Filter',
> or a noun-noun combination).
>
> Which is a better route to explore in your opinion? Which has more
> meaning to you as a developer consuming ZF?
>
> As a technical side-note, this might be required for some prefixed
> names that reduce down into PHP reserved words, for example
> Zend_CodeGenerator_Php_Class cannot become namespace
> Zend\CodeGenerator\PHP class Class due to its restrictions on class
> naming.
>
> Thoughts?
> -ralph

Reply | Threaded
Open this post in threaded view
|

Re: Poll: 2.0 and Namespace impact of class names

akrabat
In reply to this post by Ralph Schindler-2

On 16 Mar 2010, at 06:31, Ralph Schindler wrote:

> The question with namespaces is, should we use compound names to identify classes separate of the namespace itself.  This can be better demonstrated with the following code:
>
>
> use Zend\Filter as f;
> $filter = new f\Int();
>
> -- VS --
>
> use Zend\Filter as f;
> $filter = new f\IntFilter();
>
>
> In the latter example, the original class name (without the prefix) might have been Int, but this class name has been 'suffixed' with a term that gives the class name more meaning.  (In english, this means that the class name now has the adjective 'Int' and the noun 'Filter', or a noun-noun combination).
>
> Which is a better route to explore in your opinion? Which has more meaning to you as a developer consuming ZF?

Personally I prefer explicitness in my code, so if I actually used aliasing, I would be more likely to do:

use Zend as z;
$intFilter = new Filter\Int();


The problem from my point of view is that the use statement is likely to be right at the top of the file and the instantiation could be 100 lines further down. By then, I'll have have forgotten what "f" is. It's a certainty that I'll have forgotten in 6 months time when I come back to maintain it :)

As a result, I don't like the redundancy of repeating the namespace in the class name. It'll be more tying for no benefit. Having said that, it's not something I'm especially passionate about as we'll be fully qualifying in our code.

Regards,

Rob...

--
Rob Allen : http://akrabat.com
Zend Framework Tutorial: http://akrabat.com/zft
Author of Zend Framework in Action: http://www.zendframeworkinaction.com

Reply | Threaded
Open this post in threaded view
|

Re: Poll: 2.0 and Namespace impact of class names

Giorgio Sironi
In reply to this post by Andy Thompson
On Tue, Mar 16, 2010 at 8:53 AM, Andy Thompson <[hidden email]> wrote:
> Suffixing the class name with its intent seems like the best way in my
> opinion. In my own libraries, I've been frustrated with the way I might have
> 3 or 4 of the same filenames open e.g. Field\DateTime.php,
> Filter\DateTime.php, Validate\DateTime.php and Element\DateTime.php (though
> that last one I've now renamed to DateTimeSelect).

A single-word suffix really adds significance to the name. In Doctrine
2, which has a namespaced codebase, Roman told me the policy is the
basename of a class should always have a meaning by itself (i.e.
Doctrine\ORM\Persisters\SingleTablePersister;
Doctrine\ORM\Mapping\OneToOneMapping).
At least if it's not an internal class of a component, this is a
useful convention; no one cares about Doctrine\ORM\Query\TreeWalker
not being QueryTreeWalker because it's not meant to be referred out of
Doctrine\ORM\Query.

--
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi

Reply | Threaded
Open this post in threaded view
|

Re: Poll: 2.0 and Namespace impact of class names

David Caunt
I agree, the explicit names are well worth the extra typing


On 16 March 2010 10:20, Giorgio Sironi <[hidden email]> wrote:
On Tue, Mar 16, 2010 at 8:53 AM, Andy Thompson <[hidden email]> wrote:
> Suffixing the class name with its intent seems like the best way in my
> opinion. In my own libraries, I've been frustrated with the way I might have
> 3 or 4 of the same filenames open e.g. Field\DateTime.php,
> Filter\DateTime.php, Validate\DateTime.php and Element\DateTime.php (though
> that last one I've now renamed to DateTimeSelect).

A single-word suffix really adds significance to the name. In Doctrine
2, which has a namespaced codebase, Roman told me the policy is the
basename of a class should always have a meaning by itself (i.e.
Doctrine\ORM\Persisters\SingleTablePersister;
Doctrine\ORM\Mapping\OneToOneMapping).
At least if it's not an internal class of a component, this is a
useful convention; no one cares about Doctrine\ORM\Query\TreeWalker
not being QueryTreeWalker because it's not meant to be referred out of
Doctrine\ORM\Query.

--
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi



--
Save Water...Drink Ouzo !
Reply | Threaded
Open this post in threaded view
|

Re: Poll: 2.0 and Namespace impact of class names

weierophinney
Administrator
In reply to this post by Ralph Schindler-2
-- Ralph Schindler <[hidden email]> wrote
(on Tuesday, 16 March 2010, 01:31 AM -0500):
> On the Usage of Compound Names --

(My commentary below...)

> With namespaces, we have the opportunity to create aliases to
> specific namespace our code consumes.  For example, we can do
> something like this:
>
>
> <?php
> // in a script that consumes Zend Frameowrk
> use Zend\Filter as f;
>
> $filter = new f\Something.php
>
> ?>
>
>
> In the past, with fully prefixed names, it was easy to understand
> the context of a particular class since the namespace is carried
> with it. $filter = new Zend_Filter_Int(); is clearly an Integer
> filter, and the class name fully reflects that.
>
> The question with namespaces is, should we use compound names to
> identify classes separate of the namespace itself.  This can be
> better demonstrated with the following code:
>
>
> <?php
>
> use Zend\Filter as f;
>
> $filter = new f\Int();
>
> ?>
>
>
> -- VS --
>
>
> <?php
>
> use Zend\Filter as f;
>
> $filter = new f\IntFilter();
>
> ?>

Honestly, choosing "f" as an alias just seems like a bad idea from the
outset -- does it refer to "filter", or "form", or "file"? If you go
with a more explicit alias:

    use Zend\Filter;

    $filter = new Filter\Int;

the intent is already there.

I can see your point being more present if you import a single class
from a namespace:

    use Zend\Filter\Int;
    $filter = new Int();

*This* example more properly shows the issues, to my thinking. But even
then, better aliasing solves the problem:

    use Zend\Filter\Int as IntFilter;
    $filter = new IntFilter;

This requires no changes to naming whatsoever, yet still solves the
problems you describe -- but instead of doing it at the library level,
it's at the end-user level.

Yes, there will be a few places where we need to re-think names, such as
Zend\CodeGenerator and Zend\Reflection, but I think in the bulk of
instances, it shouldn't be a problem.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Reply | Threaded
Open this post in threaded view
|

Re: Poll: 2.0 and Namespace impact of class names

A.J. Brown-3
Another vote for more verbose class names.  The advantages far outweight the disadvantages (typing more). It also seperates namespacing from class naming entirely. For example, if you were writing a class to validate data specific to a service API, it might make more since for that validator to live within the namespace of those service classes, and not the global namespace:

 \Zend\Validate\FoobarUsername();

vs

\Zend\Service\Foobar\UsernameValidator();


There probably wouldn't be enough classes to justify the extra maintenance of:

\Zend\Service\Foobar\Validate\Username();


On Tue, Mar 16, 2010 at 7:57 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
-- Ralph Schindler <[hidden email]> wrote
(on Tuesday, 16 March 2010, 01:31 AM -0500):
> On the Usage of Compound Names --

(My commentary below...)

> With namespaces, we have the opportunity to create aliases to
> specific namespace our code consumes.  For example, we can do
> something like this:
>
>
> <?php
> // in a script that consumes Zend Frameowrk
> use Zend\Filter as f;
>
> $filter = new f\Something.php
>
> ?>
>
>
> In the past, with fully prefixed names, it was easy to understand
> the context of a particular class since the namespace is carried
> with it. $filter = new Zend_Filter_Int(); is clearly an Integer
> filter, and the class name fully reflects that.
>
> The question with namespaces is, should we use compound names to
> identify classes separate of the namespace itself.  This can be
> better demonstrated with the following code:
>
>
> <?php
>
> use Zend\Filter as f;
>
> $filter = new f\Int();
>
> ?>
>
>
> -- VS --
>
>
> <?php
>
> use Zend\Filter as f;
>
> $filter = new f\IntFilter();
>
> ?>

Honestly, choosing "f" as an alias just seems like a bad idea from the
outset -- does it refer to "filter", or "form", or "file"? If you go
with a more explicit alias:

   use Zend\Filter;

   $filter = new Filter\Int;

the intent is already there.

I can see your point being more present if you import a single class
from a namespace:

   use Zend\Filter\Int;
   $filter = new Int();

*This* example more properly shows the issues, to my thinking. But even
then, better aliasing solves the problem:

   use Zend\Filter\Int as IntFilter;
   $filter = new IntFilter;

This requires no changes to naming whatsoever, yet still solves the
problems you describe -- but instead of doing it at the library level,
it's at the end-user level.

Yes, there will be a few places where we need to re-think names, such as
Zend\CodeGenerator and Zend\Reflection, but I think in the bulk of
instances, it shouldn't be a problem.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc



--
A.J. Brown
Software Engineer, ZCE
blog : http://ajbrown.org
talk  : (937) 540-0099
chat : IntypicaAJ
Reply | Threaded
Open this post in threaded view
|

Re: Poll: 2.0 and Namespace impact of class names

Ralph Schindler-2
In reply to this post by weierophinney


> Honestly, choosing "f" as an alias just seems like a bad idea from the
> outset -- does it refer to "filter", or "form", or "file"? If you go

Totally agree.

> with a more explicit alias:
>
>     use Zend\Filter;
>
>     $filter = new Filter\Int;
>
> the intent is already there.
>
> I can see your point being more present if you import a single class
> from a namespace:
>
>     use Zend\Filter\Int;
>     $filter = new Int();
>
> *This* example more properly shows the issues, to my thinking. But even
> then, better aliasing solves the problem:
>
>     use Zend\Filter\Int as IntFilter;
>     $filter = new IntFilter;
>

It could be argued the other way as well:

use Zend\Filter\IntFilter as Int;

$filter = new Int();

The question is, do we rely completely on a classes placement in a
namespace as its full intent and meaning? Or do we at least give it an
identity of its own?

IntFilter is still pretty short & concise as a class name, and it's
purpose is further defined by the Zend\Filter namespace in which it resides.

Did we move away from class Abstract {} and interface Interface {}
inside of a namespace simply because they were technically impossible,
or was it because on their own, a class named Abstract inside a
namespace and an interface named Interface made little sense?

-ralph

Reply | Threaded
Open this post in threaded view
|

Re: Poll: 2.0 and Namespace impact of class names

weierophinney
Administrator
-- Ralph Schindler <[hidden email]> wrote
(on Tuesday, 16 March 2010, 02:32 PM -0500):

> > Honestly, choosing "f" as an alias just seems like a bad idea from the
> > outset -- does it refer to "filter", or "form", or "file"? If you go
>
> Totally agree.
>
> > with a more explicit alias:
> >
> >     use Zend\Filter;
> >
> >     $filter = new Filter\Int;
> >
> > the intent is already there.
> >
> > I can see your point being more present if you import a single class
> > from a namespace:
> >
> >     use Zend\Filter\Int;
> >     $filter = new Int();
> >
> > *This* example more properly shows the issues, to my thinking. But even
> > then, better aliasing solves the problem:
> >
> >     use Zend\Filter\Int as IntFilter;
> >     $filter = new IntFilter;
> >
>
> It could be argued the other way as well:
>
> use Zend\Filter\IntFilter as Int;
>
> $filter = new Int();

I'd argue that's a bad alias.

Why? Because what is "Int"? is it a class representing an integer? a
validator? a filter? The alias actually makes the name _less_
meaningful.

Aliases should be used to make shorter names that still adequately
convey the purpose or intent. The above example does not.

> The question is, do we rely completely on a classes placement in a
> namespace as its full intent and meaning? Or do we at least give it
> an identity of its own?

Namespaces are for providing context for a class. Plain and simple.

So yes -- the namespace should convey some of the meaning and intent for
the class -- and so should aliases.

> IntFilter is still pretty short & concise as a class name, and it's
> purpose is further defined by the Zend\Filter namespace in which it
> resides.

I'd argue that Zend\Filter as a namespace connotes the purpose of the
class (a filter), while "Int" connotes the strategy. "Filter" as a class
suffix feels redundant.

> Did we move away from class Abstract {} and interface Interface {}
> inside of a namespace simply because they were technically
> impossible, or was it because on their own, a class named Abstract
> inside a namespace and an interface named Interface made little
> sense?

Both -- but the latter is what fueled the discussion on the post I
started yesterday. ;-)

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc