Poll: Interfaces/Abstract class naming conventions

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

Poll: Interfaces/Abstract class naming conventions

weierophinney
Administrator
Hey, all --

I know this has been hashed out a fair bit already, and we've already
established some guidelines, but as I play with code for ZF2, I'm
beginning to question the naming conventions for Interfaces and Abstract
Classes.

When we made the decisions before, we were looking at the following
three options for interfaces:

 1. Prefix interfaces with "I" ("IFoobar").
 2. Suffix interfaces with "Interface" ("FoobarInterface")
 3. Use adjective/noun names such as "Foobarable", "Foobarist"

For abstract classes, we looked at:

 4. Prefix abstract classes with "A" ("AFoobar")
 5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
 6. Prefix abstract classes with "Base" ("BaseFoobar")
 7. Suffix abstract classes with "Base" ("FoobarBase")
 8. Use normal class names ("Foobar")

Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
they smack of Hungarian Notation, the long forms lead to really long
names, etc. Prefixing can lead to similar classes not being grouped when
doing directory listings (i.e., all abstract class or interface files
get clustered together). Also, for classes beginning with "I" or "A",
there can potentially be confusion over whether or not the given class
is supposed to be concrete. Finally, during refactoring, if you choose
to make an interface an abstract class or concrete class, or an abstract
class an interface or concrete class, you can't do so without renaming
files and classes. (That said, you'll most likely need to make other
changes anyways -- and ZF will likely never make an interface an
abstract class or vice versa.)

Regarding 3 and 8, the primary problems are that it's often hard to come
up with meaningful names that do not conflict with concrete
implementations, and that for non-native English speakers, this latter
problem becomes an even bigger obstacle. Additionally, you can't
determine which files contain abstract classes and/or interfaces just by
the filename -- you have to look in the file or look in API
documentation to determine this information.

Now, as to the issues I've seen: the word "Interface" becomes a real
pain to type (yes, even with autocompletion), and it doesn't really
connote any real information. When type-hinting, I simply know what type
I want to use -- the name doesn't need to tell me it's an interface, as
I already know that information. If I'm writing code that consumes or
interacts with the class, API docs will tell me what I need to do.

That said, I don't use Abstract classes that often, but considering they
are a foundation on which to build concrete classes (presumably to take
care of many of the nitty gritty details and leave the concrete classes
to implement specifics), I don't mind using a class suffix. "Abstract"
feels like Hungarian notation, though.

Based on my experiences writing code, I'm currently recommending that we
do the following:

 3. Use adjective/noun names for Interfaces such as "Foobarable",
    "Foobarist"
 7. Suffix abstract classes with "Base" ("FoobarableBase")

The above solve most issues - names are reasonably sized, don't smack of
Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
most importantly, meaningful. Since we already implement code review for
any code coming into trunk, I think we can even solve the issues for
non-native speakers as well.

Thoughts? Votes?

--
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: Interfaces/Abstract class naming conventions

Court Ewing
Howdy,

I think adjective/noun names for interfaces are ideal because they are far more inline with the naming conventions already used in SPL, and I think that is something we should be striving to do wherever possible.

I support prefixes for abstract classes rather than suffixes, but it seems that has long been shot down as an option.

Regardless of whether we do prefixes or suffixes though, I think we should use the word "Abstract" rather than "Base".  All programmatic dogma aside, if I were to describe an abstract class to someone else (take an abstract Triangle class), I would tell the person that this is an abstract representation of a triangle; I wouldn't say it is a base representation of a triangle.  If you're going to cite hungarian notation as the reason for not using the word "abstract", then I don't know how you can justify using any keyword to denote that it is abstract.

-Court

On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
Hey, all --

I know this has been hashed out a fair bit already, and we've already
established some guidelines, but as I play with code for ZF2, I'm
beginning to question the naming conventions for Interfaces and Abstract
Classes.

When we made the decisions before, we were looking at the following
three options for interfaces:

 1. Prefix interfaces with "I" ("IFoobar").
 2. Suffix interfaces with "Interface" ("FoobarInterface")
 3. Use adjective/noun names such as "Foobarable", "Foobarist"

For abstract classes, we looked at:

 4. Prefix abstract classes with "A" ("AFoobar")
 5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
 6. Prefix abstract classes with "Base" ("BaseFoobar")
 7. Suffix abstract classes with "Base" ("FoobarBase")
 8. Use normal class names ("Foobar")

Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
they smack of Hungarian Notation, the long forms lead to really long
names, etc. Prefixing can lead to similar classes not being grouped when
doing directory listings (i.e., all abstract class or interface files
get clustered together). Also, for classes beginning with "I" or "A",
there can potentially be confusion over whether or not the given class
is supposed to be concrete. Finally, during refactoring, if you choose
to make an interface an abstract class or concrete class, or an abstract
class an interface or concrete class, you can't do so without renaming
files and classes. (That said, you'll most likely need to make other
changes anyways -- and ZF will likely never make an interface an
abstract class or vice versa.)

Regarding 3 and 8, the primary problems are that it's often hard to come
up with meaningful names that do not conflict with concrete
implementations, and that for non-native English speakers, this latter
problem becomes an even bigger obstacle. Additionally, you can't
determine which files contain abstract classes and/or interfaces just by
the filename -- you have to look in the file or look in API
documentation to determine this information.

Now, as to the issues I've seen: the word "Interface" becomes a real
pain to type (yes, even with autocompletion), and it doesn't really
connote any real information. When type-hinting, I simply know what type
I want to use -- the name doesn't need to tell me it's an interface, as
I already know that information. If I'm writing code that consumes or
interacts with the class, API docs will tell me what I need to do.

That said, I don't use Abstract classes that often, but considering they
are a foundation on which to build concrete classes (presumably to take
care of many of the nitty gritty details and leave the concrete classes
to implement specifics), I don't mind using a class suffix. "Abstract"
feels like Hungarian notation, though.

Based on my experiences writing code, I'm currently recommending that we
do the following:

 3. Use adjective/noun names for Interfaces such as "Foobarable",
   "Foobarist"
 7. Suffix abstract classes with "Base" ("FoobarableBase")

The above solve most issues - names are reasonably sized, don't smack of
Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
most importantly, meaningful. Since we already implement code review for
any code coming into trunk, I think we can even solve the issues for
non-native speakers as well.

Thoughts? Votes?

--
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: Interfaces/Abstract class naming conventions

weierophinney
Administrator
-- Court Ewing <[hidden email]> wrote
(on Monday, 15 March 2010, 04:21 PM -0400):

> I think adjective/noun names for interfaces are ideal because they are far more
> inline with the naming conventions already used in SPL, and I think that is
> something we should be striving to do wherever possible.
>
> I support prefixes for abstract classes rather than suffixes, but it seems that
> has long been shot down as an option.
>
> Regardless of whether we do prefixes or suffixes though, I think we should use
> the word "Abstract" rather than "Base".  All programmatic dogma aside, if I
> were to describe an abstract class to someone else (take an abstract Triangle
> class), I would tell the person that this is an abstract representation of a
> triangle; I wouldn't say it is a base representation of a triangle.  If you're
> going to cite hungarian notation as the reason for not using the word
> "abstract", then I don't know how you can justify using any keyword to denote
> that it is abstract.

Excellent and well-considered reply -- thanks!

> On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>
>     Hey, all --
>
>     I know this has been hashed out a fair bit already, and we've already
>     established some guidelines, but as I play with code for ZF2, I'm
>     beginning to question the naming conventions for Interfaces and Abstract
>     Classes.
>
>     When we made the decisions before, we were looking at the following
>     three options for interfaces:
>
>      1. Prefix interfaces with "I" ("IFoobar").
>      2. Suffix interfaces with "Interface" ("FoobarInterface")
>      3. Use adjective/noun names such as "Foobarable", "Foobarist"
>
>     For abstract classes, we looked at:
>
>      4. Prefix abstract classes with "A" ("AFoobar")
>      5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>      6. Prefix abstract classes with "Base" ("BaseFoobar")
>      7. Suffix abstract classes with "Base" ("FoobarBase")
>      8. Use normal class names ("Foobar")
>
>     Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
>     they smack of Hungarian Notation, the long forms lead to really long
>     names, etc. Prefixing can lead to similar classes not being grouped when
>     doing directory listings (i.e., all abstract class or interface files
>     get clustered together). Also, for classes beginning with "I" or "A",
>     there can potentially be confusion over whether or not the given class
>     is supposed to be concrete. Finally, during refactoring, if you choose
>     to make an interface an abstract class or concrete class, or an abstract
>     class an interface or concrete class, you can't do so without renaming
>     files and classes. (That said, you'll most likely need to make other
>     changes anyways -- and ZF will likely never make an interface an
>     abstract class or vice versa.)
>
>     Regarding 3 and 8, the primary problems are that it's often hard to come
>     up with meaningful names that do not conflict with concrete
>     implementations, and that for non-native English speakers, this latter
>     problem becomes an even bigger obstacle. Additionally, you can't
>     determine which files contain abstract classes and/or interfaces just by
>     the filename -- you have to look in the file or look in API
>     documentation to determine this information.
>
>     Now, as to the issues I've seen: the word "Interface" becomes a real
>     pain to type (yes, even with autocompletion), and it doesn't really
>     connote any real information. When type-hinting, I simply know what type
>     I want to use -- the name doesn't need to tell me it's an interface, as
>     I already know that information. If I'm writing code that consumes or
>     interacts with the class, API docs will tell me what I need to do.
>
>     That said, I don't use Abstract classes that often, but considering they
>     are a foundation on which to build concrete classes (presumably to take
>     care of many of the nitty gritty details and leave the concrete classes
>     to implement specifics), I don't mind using a class suffix. "Abstract"
>     feels like Hungarian notation, though.
>
>     Based on my experiences writing code, I'm currently recommending that we
>     do the following:
>
>      3. Use adjective/noun names for Interfaces such as "Foobarable",
>        "Foobarist"
>      7. Suffix abstract classes with "Base" ("FoobarableBase")
>
>     The above solve most issues - names are reasonably sized, don't smack of
>     Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
>     most importantly, meaningful. Since we already implement code review for
>     any code coming into trunk, I think we can even solve the issues for
>     non-native speakers as well.
>
>     Thoughts? Votes?
>
>     --
>     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
>
>

--
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: Interfaces/Abstract class naming conventions

David Caunt
In reply to this post by Court Ewing
Hi Matthew,

I strongly agree with the choice of 3, with 2 a distant second. As Court says, the SPL contains Countable, Serializable and many others, and I've always found these intuitive without giving it much thought. Seems sensible to follow a PHP convention if there's no significant benefit of another style.

For abstract classes there are more options, and none seem to particularly stand out as ideal. What I like about the ZF1 system is that class names do contain an indicator that they are Abstract (suffix). Use of the word Base introduces some ambiguity (albeit small) so I'd prefer the word Abstract, but an Abstract suffix (5) only feels sensible if Interfaces have the Interface suffix. Perhaps a Base suffix is the best solution! I guess I'm happy to be persuaded.

David

On 15 March 2010 20:21, Court Ewing <[hidden email]> wrote:
Howdy,

I think adjective/noun names for interfaces are ideal because they are far more inline with the naming conventions already used in SPL, and I think that is something we should be striving to do wherever possible.

I support prefixes for abstract classes rather than suffixes, but it seems that has long been shot down as an option.

Regardless of whether we do prefixes or suffixes though, I think we should use the word "Abstract" rather than "Base".  All programmatic dogma aside, if I were to describe an abstract class to someone else (take an abstract Triangle class), I would tell the person that this is an abstract representation of a triangle; I wouldn't say it is a base representation of a triangle.  If you're going to cite hungarian notation as the reason for not using the word "abstract", then I don't know how you can justify using any keyword to denote that it is abstract.

-Court


On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
Hey, all --

I know this has been hashed out a fair bit already, and we've already
established some guidelines, but as I play with code for ZF2, I'm
beginning to question the naming conventions for Interfaces and Abstract
Classes.

When we made the decisions before, we were looking at the following
three options for interfaces:

 1. Prefix interfaces with "I" ("IFoobar").
 2. Suffix interfaces with "Interface" ("FoobarInterface")
 3. Use adjective/noun names such as "Foobarable", "Foobarist"

For abstract classes, we looked at:

 4. Prefix abstract classes with "A" ("AFoobar")
 5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
 6. Prefix abstract classes with "Base" ("BaseFoobar")
 7. Suffix abstract classes with "Base" ("FoobarBase")
 8. Use normal class names ("Foobar")

Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
they smack of Hungarian Notation, the long forms lead to really long
names, etc. Prefixing can lead to similar classes not being grouped when
doing directory listings (i.e., all abstract class or interface files
get clustered together). Also, for classes beginning with "I" or "A",
there can potentially be confusion over whether or not the given class
is supposed to be concrete. Finally, during refactoring, if you choose
to make an interface an abstract class or concrete class, or an abstract
class an interface or concrete class, you can't do so without renaming
files and classes. (That said, you'll most likely need to make other
changes anyways -- and ZF will likely never make an interface an
abstract class or vice versa.)

Regarding 3 and 8, the primary problems are that it's often hard to come
up with meaningful names that do not conflict with concrete
implementations, and that for non-native English speakers, this latter
problem becomes an even bigger obstacle. Additionally, you can't
determine which files contain abstract classes and/or interfaces just by
the filename -- you have to look in the file or look in API
documentation to determine this information.

Now, as to the issues I've seen: the word "Interface" becomes a real
pain to type (yes, even with autocompletion), and it doesn't really
connote any real information. When type-hinting, I simply know what type
I want to use -- the name doesn't need to tell me it's an interface, as
I already know that information. If I'm writing code that consumes or
interacts with the class, API docs will tell me what I need to do.

That said, I don't use Abstract classes that often, but considering they
are a foundation on which to build concrete classes (presumably to take
care of many of the nitty gritty details and leave the concrete classes
to implement specifics), I don't mind using a class suffix. "Abstract"
feels like Hungarian notation, though.

Based on my experiences writing code, I'm currently recommending that we
do the following:

 3. Use adjective/noun names for Interfaces such as "Foobarable",
   "Foobarist"
 7. Suffix abstract classes with "Base" ("FoobarableBase")

The above solve most issues - names are reasonably sized, don't smack of
Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
most importantly, meaningful. Since we already implement code review for
any code coming into trunk, I think we can even solve the issues for
non-native speakers as well.

Thoughts? Votes?

--
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




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

Re: Poll: Interfaces/Abstract class naming conventions

Andy Thompson
In reply to this post by weierophinney
Hi,

I'm not keen on adjective or noun names, I can't even fathome names like
Elementable or Helpable. It sounds even worse if needing to define
multi-word interfaces, e.g ControllerPlugable

However the shortening of FoobarAbstract to FoobarBase seems to make
sense. Perhaps something similar could be done to FoobarInterface, say
FoobarSpec?

Regards

Andy

On 15/03/2010 19:58, Matthew Weier O'Phinney wrote:

> Hey, all --
>
> I know this has been hashed out a fair bit already, and we've already
> established some guidelines, but as I play with code for ZF2, I'm
> beginning to question the naming conventions for Interfaces and Abstract
> Classes.
>
> When we made the decisions before, we were looking at the following
> three options for interfaces:
>
>   1. Prefix interfaces with "I" ("IFoobar").
>   2. Suffix interfaces with "Interface" ("FoobarInterface")
>   3. Use adjective/noun names such as "Foobarable", "Foobarist"
>
> For abstract classes, we looked at:
>
>   4. Prefix abstract classes with "A" ("AFoobar")
>   5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>   6. Prefix abstract classes with "Base" ("BaseFoobar")
>   7. Suffix abstract classes with "Base" ("FoobarBase")
>   8. Use normal class names ("Foobar")
>
> Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
> they smack of Hungarian Notation, the long forms lead to really long
> names, etc. Prefixing can lead to similar classes not being grouped when
> doing directory listings (i.e., all abstract class or interface files
> get clustered together). Also, for classes beginning with "I" or "A",
> there can potentially be confusion over whether or not the given class
> is supposed to be concrete. Finally, during refactoring, if you choose
> to make an interface an abstract class or concrete class, or an abstract
> class an interface or concrete class, you can't do so without renaming
> files and classes. (That said, you'll most likely need to make other
> changes anyways -- and ZF will likely never make an interface an
> abstract class or vice versa.)
>
> Regarding 3 and 8, the primary problems are that it's often hard to come
> up with meaningful names that do not conflict with concrete
> implementations, and that for non-native English speakers, this latter
> problem becomes an even bigger obstacle. Additionally, you can't
> determine which files contain abstract classes and/or interfaces just by
> the filename -- you have to look in the file or look in API
> documentation to determine this information.
>
> Now, as to the issues I've seen: the word "Interface" becomes a real
> pain to type (yes, even with autocompletion), and it doesn't really
> connote any real information. When type-hinting, I simply know what type
> I want to use -- the name doesn't need to tell me it's an interface, as
> I already know that information. If I'm writing code that consumes or
> interacts with the class, API docs will tell me what I need to do.
>
> That said, I don't use Abstract classes that often, but considering they
> are a foundation on which to build concrete classes (presumably to take
> care of many of the nitty gritty details and leave the concrete classes
> to implement specifics), I don't mind using a class suffix. "Abstract"
> feels like Hungarian notation, though.
>
> Based on my experiences writing code, I'm currently recommending that we
> do the following:
>
>   3. Use adjective/noun names for Interfaces such as "Foobarable",
>      "Foobarist"
>   7. Suffix abstract classes with "Base" ("FoobarableBase")
>
> The above solve most issues - names are reasonably sized, don't smack of
> Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
> most importantly, meaningful. Since we already implement code review for
> any code coming into trunk, I think we can even solve the issues for
> non-native speakers as well.
>
> Thoughts? Votes?
>
>    

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

padraicb
In reply to this post by Court Ewing
I agree with Matthew on the rest, except that, as with Court, I prefer Abstract to Base. Longer term albeit, it makes more sense than Base which can suggest a broader use meaning (e.g. a non-Abstract super class). Under that meaning, Base can be any parent class so the indication of a class being Abstract is no longer a certainty without referring to API docs (or the code itself).

Paddy
 
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative



From: Court Ewing <[hidden email]>
To: [hidden email]
Sent: Mon, March 15, 2010 8:21:26 PM
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming conventions

Howdy,

I think adjective/noun names for interfaces are ideal because they are far more inline with the naming conventions already used in SPL, and I think that is something we should be striving to do wherever possible.

I support prefixes for abstract classes rather than suffixes, but it seems that has long been shot down as an option.

Regardless of whether we do prefixes or suffixes though, I think we should use the word "Abstract" rather than "Base".  All programmatic dogma aside, if I were to describe an abstract class to someone else (take an abstract Triangle class), I would tell the person that this is an abstract representation of a triangle; I wouldn't say it is a base representation of a triangle.  If you're going to cite hungarian notation as the reason for not using the word "abstract", then I don't know how you can justify using any keyword to denote that it is abstract.

-Court

On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
Hey, all --

I know this has been hashed out a fair bit already, and we've already
established some guidelines, but as I play with code for ZF2, I'm
beginning to question the naming conventions for Interfaces and Abstract
Classes.

When we made the decisions before, we were looking at the following
three options for interfaces:

 1. Prefix interfaces with "I" ("IFoobar").
 2. Suffix interfaces with "Interface" ("FoobarInterface")
 3. Use adjective/noun names such as "Foobarable", "Foobarist"

For abstract classes, we looked at:

 4. Prefix abstract classes with "A" ("AFoobar")
 5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
 6. Prefix abstract classes with "Base" ("BaseFoobar")
 7. Suffix abstract classes with "Base" ("FoobarBase")
 8. Use normal class names ("Foobar")

Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
they smack of Hungarian Notation, the long forms lead to really long
names, etc. Prefixing can lead to similar classes not being grouped when
doing directory listings (i.e., all abstract class or interface files
get clustered together). Also, for classes beginning with "I" or "A",
there can potentially be confusion over whether or not the given class
is supposed to be concrete. Finally, during refactoring, if you choose
to make an interface an abstract class or concrete class, or an abstract
class an interface or concrete class, you can't do so without renaming
files and classes. (That said, you'll most likely need to make other
changes anyways -- and ZF will likely never make an interface an
abstract class or vice versa.)

Regarding 3 and 8, the primary problems are that it's often hard to come
up with meaningful names that do not conflict with concrete
implementations, and that for non-native English speakers, this latter
problem becomes an even bigger obstacle. Additionally, you can't
determine which files contain abstract classes and/or interfaces just by
the filename -- you have to look in the file or look in API
documentation to determine this information.

Now, as to the issues I've seen: the word "Interface" becomes a real
pain to type (yes, even with autocompletion), and it doesn't really
connote any real information. When type-hinting, I simply know what type
I want to use -- the name doesn't need to tell me it's an interface, as
I already know that information. If I'm writing code that consumes or
interacts with the class, API docs will tell me what I need to do.

That said, I don't use Abstract classes that often, but considering they
are a foundation on which to build concrete classes (presumably to take
care of many of the nitty gritty details and leave the concrete classes
to implement specifics), I don't mind using a class suffix. "Abstract"
feels like Hungarian notation, though.

Based on my experiences writing code, I'm currently recommending that we
do the following:

 3. Use adjective/noun names for Interfaces such as "Foobarable",
   "Foobarist"
 7. Suffix abstract classes with "Base" ("FoobarableBase")

The above solve most issues - names are reasonably sized, don't smack of
Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
most importantly, meaningful. Since we already implement code review for
any code coming into trunk, I think we can even solve the issues for
non-native speakers as well.

Thoughts? Votes?

--
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: Interfaces/Abstract class naming conventions

Stanislav Malyshev
In reply to this post by weierophinney
Hi!

> When we made the decisions before, we were looking at the following
> three options for interfaces:
>
>   1. Prefix interfaces with "I" ("IFoobar").
>   2. Suffix interfaces with "Interface" ("FoobarInterface")
>   3. Use adjective/noun names such as "Foobarable", "Foobarist"

I like (3) better, with small note that it doesn't have to be specific
form - i.e. just Element is better that trying to stick an unnatural
prefix at the end of it (of course, if there's a natural one, like
Countable, we're lucky :)
Now, the collision here is - what if we had both interface and abstract
implementation of it - i.e. both Element interface and Element abstract
class?
I think it would make sense to do it this way:

interface Element {}
abstract class ElementBase implements Element {}
class ConcreteElement extends ElementBase {}
class FancyElement implements Element {}

it would make code using Element look like:

function addElement(Element $element) {}

and:

if($element instanceof Element) { $element->doStuff(); }

which IMHO is both clear and compact (note that you would rarely use
ElementBase in the code above since your base reference type is supposed
to be Element, and ElementBase is just a code reuse tool).
--
Stanislav Malyshev, Zend Software Architect
[hidden email]   http://www.zend.com/
(408)253-8829   MSN: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Giorgio Sironi
In reply to this post by weierophinney
3) is really a good option if the chosen adjectives are meaningful.
The problem is the most valuable names are currently taken up from the
concrete classes or from the Facades, which may be subjected to
renaming to accomodate interface. All type hints and documentation of
dependencies references the interface names, so they should be given
precedence; the actual implementor is, in fact, an implementation
detail.
For instance some name refactorings may be:
Zend_Controller_Router_Interface => Zend_Controller_Router (no Facade
currently exists)
Zend_Filter => Zend_Filter_Chain, Zend_Filter_Interface => Zend_Filter
(Facade replaced, porting scripts could replace the occurrences)
Zend_View => Zend_View_NativePhp, Zend_View_Interface => Zend_View
Zend_Db_Adapter extracted as an interface (currently does not exist.)
5) and 7) are somewhat equivalent since abstract classes are
references only with the *extends* keyword and never in type hinting,
docblocks and such. As long as they are consistent they should not
create problems.
Both concrete classes and abstract ones should be referenced
*sparingly* respectively in factories/factory methods and extends
keywords. So in my opinion the focus should be in keeping natural and
simple the interface names.


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

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Eric Clemmons
In reply to this post by padraicb
<base href="x-msg://67/">
I agree with Abstract as it ties closely with the naming scheme that many learned in other OO languages.  Base tends (in Javascript modules and PHP) to contain application-specific (non-portable) code while Abstract is self-contained.

I am curious about the dangers of "Foobarable" notation, which reminds me of the issues Django Admin has when you have a "Company" object which is pluralized in "Companies".  Should we perform most new file creation through Zend Tool, I would think this would be problematic.

</2 cents>

-Eric Clemmons

On Mar 15, 2010, at 4:03 PM, Pádraic Brady wrote:

I agree with Matthew on the rest, except that, as with Court, I prefer Abstract to Base. Longer term albeit, it makes more sense than Base which can suggest a broader use meaning (e.g. a non-Abstract super class). Under that meaning, Base can be any parent class so the indication of a class being Abstract is no longer a certainty without referring to API docs (or the code itself).

Paddy
 
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative



From: Court Ewing <[hidden email]>
To: [hidden email]
Sent: Mon, March 15, 2010 8:21:26 PM
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming conventions

Howdy,

I think adjective/noun names for interfaces are ideal because they are far more inline with the naming conventions already used in SPL, and I think that is something we should be striving to do wherever possible.

I support prefixes for abstract classes rather than suffixes, but it seems that has long been shot down as an option.

Regardless of whether we do prefixes or suffixes though, I think we should use the word "Abstract" rather than "Base".  All programmatic dogma aside, if I were to describe an abstract class to someone else (take an abstract Triangle class), I would tell the person that this is an abstract representation of a triangle; I wouldn't say it is a base representation of a triangle.  If you're going to cite hungarian notation as the reason for not using the word "abstract", then I don't know how you can justify using any keyword to denote that it is abstract.

-Court

On Mon, Mar 15, 2010 at 3:58 PM, Matthew Weier O'Phinney <[hidden email]> wrote:
Hey, all --

I know this has been hashed out a fair bit already, and we've already
established some guidelines, but as I play with code for ZF2, I'm
beginning to question the naming conventions for Interfaces and Abstract
Classes.

When we made the decisions before, we were looking at the following
three options for interfaces:

 1. Prefix interfaces with "I" ("IFoobar").
 2. Suffix interfaces with "Interface" ("FoobarInterface")
 3. Use adjective/noun names such as "Foobarable", "Foobarist"

For abstract classes, we looked at:

 4. Prefix abstract classes with "A" ("AFoobar")
 5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
 6. Prefix abstract classes with "Base" ("BaseFoobar")
 7. Suffix abstract classes with "Base" ("FoobarBase")
 8. Use normal class names ("Foobar")

Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
they smack of Hungarian Notation, the long forms lead to really long
names, etc. Prefixing can lead to similar classes not being grouped when
doing directory listings (i.e., all abstract class or interface files
get clustered together). Also, for classes beginning with "I" or "A",
there can potentially be confusion over whether or not the given class
is supposed to be concrete. Finally, during refactoring, if you choose
to make an interface an abstract class or concrete class, or an abstract
class an interface or concrete class, you can't do so without renaming
files and classes. (That said, you'll most likely need to make other
changes anyways -- and ZF will likely never make an interface an
abstract class or vice versa.)

Regarding 3 and 8, the primary problems are that it's often hard to come
up with meaningful names that do not conflict with concrete
implementations, and that for non-native English speakers, this latter
problem becomes an even bigger obstacle. Additionally, you can't
determine which files contain abstract classes and/or interfaces just by
the filename -- you have to look in the file or look in API
documentation to determine this information.

Now, as to the issues I've seen: the word "Interface" becomes a real
pain to type (yes, even with autocompletion), and it doesn't really
connote any real information. When type-hinting, I simply know what type
I want to use -- the name doesn't need to tell me it's an interface, as
I already know that information. If I'm writing code that consumes or
interacts with the class, API docs will tell me what I need to do.

That said, I don't use Abstract classes that often, but considering they
are a foundation on which to build concrete classes (presumably to take
care of many of the nitty gritty details and leave the concrete classes
to implement specifics), I don't mind using a class suffix. "Abstract"
feels like Hungarian notation, though.

Based on my experiences writing code, I'm currently recommending that we
do the following:

 3. Use adjective/noun names for Interfaces such as "Foobarable",
   "Foobarist"
 7. Suffix abstract classes with "Base" ("FoobarableBase")

The above solve most issues - names are reasonably sized, don't smack of
Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
most importantly, meaningful. Since we already implement code review for
any code coming into trunk, I think we can even solve the issues for
non-native speakers as well.

Thoughts? Votes?

--
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: Interfaces/Abstract class naming conventions

hobodave
In reply to this post by padraicb
<base href="x-msg://356/">
I too prefer Abstract to Base. I often use Base in my applications for non-abstract super classes which extend the abstract ZF classes. To me Abstract means I can't instantiate it, but Base means I *could* if I wanted.

On Mar 15, 2010, at 4:03 PM, Pádraic Brady wrote:

I agree with Matthew on the rest, except that, as with Court, I prefer Abstract to Base. Longer term albeit, it makes more sense than Base which can suggest a broader use meaning (e.g. a non-Abstract super class). Under that meaning, Base can be any parent class so the indication of a class being Abstract is no longer a certainty without referring to API docs (or the code itself).

Paddy
 
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative


Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Chris Boyce
In reply to this post by Stanislav Malyshev
>>  3. Use adjective/noun names such as "Foobarable", "Foobarist"
>
> I like (3) better, with small note that it doesn't have to be specific form
> - i.e. just Element is better that trying to stick an unnatural prefix at
> the end of it (of course, if there's a natural one, like Countable, we're
> lucky :)

I like this approach. To me, it seems intuitive and not quite as
awkward as an Abstract suffix. For example, Countable seems much more
transparent than CountAbstract. Also, Element seems sufficiently vague
(or "abstract") that in a particular application I might not expect it
to be a concrete class. However, it might be enlightening to have a
sample of a broad selection of class names in the various conventions
to see shortcomings that may not be obvious with more convenient
examples.

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Ralf Eggert
In reply to this post by weierophinney
Hi Matthew,

Could you feed this discussion with some real world examples? For
example "Foobarable" and "Foobarist" sound a little weird to me.

Please name some interfaces with their current name and the future
variations for the options 1 to 8. Maybe this could help a little more
in the discussion. For example how should Zend_Acl_Role_Interface oder
Zend_Captcha_Adapter or Zend_Pdf_ElementFactory_Interface be renamed?

Thanks and best regards,

Ralf

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Dolf Schimmel
Regarding abstract classes; I'm in favor of #8. Okay, it may make it a
little more difficult to think of meaningful names, but once the
author has thought of such name, people using the class can much more
easily judge by its name what it does. Think of Zend_View and
Zend_View_Abstract. Currently, it's totally unclear what the
difference between the two is (e.g. 'when am I to extend which?').
This could of course be easily solved by giving the latter a much more
descriptive names.

Regards,

Dolf Schimmel
Freeaqingme

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

akrabat
In reply to this post by weierophinney

On 15 Mar 2010, at 19:58, Matthew Weier O'Phinney wrote:

> 1. Prefix interfaces with "I" ("IFoobar").
> 2. Suffix interfaces with "Interface" ("FoobarInterface")
> 3. Use adjective/noun names such as "Foobarable", "Foobarist"
>
> For abstract classes, we looked at:
>
> 4. Prefix abstract classes with "A" ("AFoobar")
> 5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
> 6. Prefix abstract classes with "Base" ("BaseFoobar")
> 7. Suffix abstract classes with "Base" ("FoobarBase")
> 8. Use normal class names ("Foobar")

[snip]

> Based on my experiences writing code, I'm currently recommending that we
> do the following:
>
> 3. Use adjective/noun names for Interfaces such as "Foobarable",
>    "Foobarist"
> 7. Suffix abstract classes with "Base" ("FoobarableBase")
>
> The above solve most issues - names are reasonably sized, don't smack of
> Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
> most importantly, meaningful. Since we already implement code review for
> any code coming into trunk, I think we can even solve the issues for
> non-native speakers as well.


I like 3 too. I'm with Court on the "it's like the SPL". In theory it would also make the interface name sound better. However, some renamings can sound a bit odd in practice.

Looking at some actual interfaces we have at the moment:

These are definite improvements:
* Zend_Filter_Compress_CompressInterface => Zend_Filter_Compress_Compressable
* Zend_Oauth_Config_ConfigInterface => Zend_Oauth_Configurable
* Zend_Queue_Stomp_Client_ConnectionInterface => Zend_Queue_Stomp_Client_Connectable

but then you also get:
* Zend_Serializer_Adapter_AdapterInterface becomes Zend_Serializer_Adaptable
* Zend_Feed_Pubsubhubbub_CallbackInterface => Zend_Feed_Pubsubhubbub_Callbackable

and some complete renames:
* Zend_Currency_CurrencyInterface => Zend_Currency_Exchangable / Zend_Currency_Convertable
* Zend_Log_FactoryInterface => Zend_ Loggable

which maybe sound less good...

The principle is sound though. I suspect that it's just a case that some interfaces need to be re-evaluated as to why they exist and then named for what they are actually there for.


As for abstract classes, I'm in favour of "Abstract" in preference to "Base" as if we're going to have an artificial construct, "Abstract" is completely unambiguous. I would rather try and remove as many as possible and rename to a proper name though. e.g. Zend_Db_Table_Abstract and Zend_Db_Table could be merged to just Zend_Db_Table, especially as Zend_Db_Table causes an E_STRICT warning due to redefining the __construct() method signature :)


Regards,

Rob...






Zend_View_Helper_Abstract => Zend_View_Helper



Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Lukas Köll
In reply to this post by Ralf Eggert
Hi Ralf,
this is my first "get-in-touch" with the zf-contributor list so please feel free to draw my attention to any mistakes i make.

For Zend_Acl_Role I would have thought that Zend_Acl_Role should be the new Interface, while for the default implementation there should be something like Zend_Acl_Role_Default/Text. As I have never needed to implement custom acl-roles myself I also don't know which possible use cases a custom implementation of a Zend_Acl_Role Interface might have. I also think that an interface named Zend_Acl_Role is much more reader-friendly than Zend_Acl_Role_Interface.

Zend_Captcha_Adapter might from my point of view stay just as-is (because, actually, everything that implements Zend_Captcha_Adapter CAN ACT AS an adapter), Zend_Pdf_ElementFactory_Interface should in my opinion also be renamed to Zend_Pdf_ElementFactory and move the default implementation to something like Zend_Pdf_ElementFactory_Default (maybe someone can come up with something better then "Default" ?) - again, reading "instanceof Zend_Pdf_ElementFactory" feels at least to me much more natural than "instanceof Zend_Pdf_ElementFactory_Interface"

Zend_Validate would by the way be a good example for adding adjectives. My proposal: Zend_Validateable or Zend_Validate_Validateable

best regards

Lukas Köll

Am 15.03.2010 um 22:34 schrieb Ralf Eggert:

> Hi Matthew,
>
> Could you feed this discussion with some real world examples? For
> example "Foobarable" and "Foobarist" sound a little weird to me.
>
> Please name some interfaces with their current name and the future
> variations for the options 1 to 8. Maybe this could help a little more
> in the discussion. For example how should Zend_Acl_Role_Interface oder
> Zend_Captcha_Adapter or Zend_Pdf_ElementFactory_Interface be renamed?
>
> Thanks and best regards,
>
> Ralf
>

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

padraicb
Lukas,

You're right. There...short and sweet confirmation ;). If we take up Matthew's suggestion the interface would be either a noun or an adjective, so something like the current Zend_Feed_Subscriber_CallbackInterface would simply be shortened to Zend_Feed_Subscriber_Callback. Unfortunately, we're likely to meet conflicts - in this example Zend_Feed_Subscriber_Callback is already a concrete implementation so it would need to be renamed. To what, I'm not sure - Zend_Feed_Subscriber_Callback_Basic? This lengthens the concrete class name and also shifts its directory position to boot, so perhaps simply Zend_Feed_Subscriber_CallbackBasic. Oddly I seem to do this an awful lot :P. Since Interface was our marker, the nouns and adjectives were used for concrete class names instead. Going to be...interesting...reversing all that in a sensible way.

Main thing to come out of any confusion here though, is simply to stick with standard English. If a new interface name looks decidedly odd or uncomfortable, it's probably just as well backtracking a little and contemplating a more sensible name. Some of the earlier examples like Foobarable and Foobarist missed the simplicity of "Foobar" - it's a noun, right? If it happens to be currently a concrete class, well, it will just have to move over and make way for the Interface. It will be somewhat disruptive in this sense.

Paddy
 
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative



From: Lukas Köll <[hidden email]>
To: [hidden email]
Sent: Mon, March 15, 2010 10:09:39 PM
Subject: Re: [zf-contributors] Poll: Interfaces/Abstract class naming conventions

Hi Ralf,
this is my first "get-in-touch" with the zf-contributor list so please feel free to draw my attention to any mistakes i make.

For Zend_Acl_Role I would have thought that Zend_Acl_Role should be the new Interface, while for the default implementation there should be something like Zend_Acl_Role_Default/Text. As I have never needed to implement custom acl-roles myself I also don't know which possible use cases a custom implementation of a Zend_Acl_Role Interface might have. I also think that an interface named Zend_Acl_Role is much more reader-friendly than Zend_Acl_Role_Interface.

Zend_Captcha_Adapter might from my point of view stay just as-is (because, actually, everything that implements Zend_Captcha_Adapter CAN ACT AS an adapter), Zend_Pdf_ElementFactory_Interface should in my opinion also be renamed to Zend_Pdf_ElementFactory and move the default implementation to something like Zend_Pdf_ElementFactory_Default (maybe someone can come up with something better then "Default" ?) - again, reading "instanceof Zend_Pdf_ElementFactory" feels at least to me much more natural than "instanceof Zend_Pdf_ElementFactory_Interface"

Zend_Validate would by the way be a good example for adding adjectives. My proposal: Zend_Validateable or Zend_Validate_Validateable

best regards

Lukas Köll

Am 15.03.2010 um 22:34 schrieb Ralf Eggert:

> Hi Matthew,
>
> Could you feed this discussion with some real world examples? For
> example "Foobarable" and "Foobarist" sound a little weird to me.
>
> Please name some interfaces with their current name and the future
> variations for the options 1 to 8. Maybe this could help a little more
> in the discussion. For example how should Zend_Acl_Role_Interface oder
> Zend_Captcha_Adapter or Zend_Pdf_ElementFactory_Interface be renamed?
>
> Thanks and best regards,
>
> Ralf
>

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

drm-4
In reply to this post by weierophinney
Hi,


Regarding interfaces I'm in favor of 1. I've found that in theory the
"readable English" naming feels better (as in e.g. Countable), but in
practice not every thing is very well translated into adjectives. Nouns
on the other hand render ambiguity. An "Element" interface might clash
with an Element (base, not abstract per se) class, but the 'I' prefix
gives the author all freedom to however he thinks the interface is named
best, including the no 3 convention, e.g. IComparable. Last but not
least, naming rules in coding standards are ideally checkable by a code
sniffer imho. That's impossible if they're arbitrarily named.

Nonetheless, following the SPL naming style makes perfect sense to me too.

On abstract classes I've always preferred the Abstract prefix, so a
variant of 6.

But at the end of the day it wouldn't be something I'd fight over, after
all it remains a matter of taste :-)


drm / Gerard

Matthew Weier O'Phinney wrote:

> Hey, all --
>
> I know this has been hashed out a fair bit already, and we've already
> established some guidelines, but as I play with code for ZF2, I'm
> beginning to question the naming conventions for Interfaces and Abstract
> Classes.
>
> When we made the decisions before, we were looking at the following
> three options for interfaces:
>
>  1. Prefix interfaces with "I" ("IFoobar").
>  2. Suffix interfaces with "Interface" ("FoobarInterface")
>  3. Use adjective/noun names such as "Foobarable", "Foobarist"
>
> For abstract classes, we looked at:
>
>  4. Prefix abstract classes with "A" ("AFoobar")
>  5. Suffix abstract classes with "Abstract" ("FoobarAbstract")
>  6. Prefix abstract classes with "Base" ("BaseFoobar")
>  7. Suffix abstract classes with "Base" ("FoobarBase")
>  8. Use normal class names ("Foobar")
>
> Regarding 1, 2, and 4-7, the arguments against were fairly numerous:
> they smack of Hungarian Notation, the long forms lead to really long
> names, etc. Prefixing can lead to similar classes not being grouped when
> doing directory listings (i.e., all abstract class or interface files
> get clustered together). Also, for classes beginning with "I" or "A",
> there can potentially be confusion over whether or not the given class
> is supposed to be concrete. Finally, during refactoring, if you choose
> to make an interface an abstract class or concrete class, or an abstract
> class an interface or concrete class, you can't do so without renaming
> files and classes. (That said, you'll most likely need to make other
> changes anyways -- and ZF will likely never make an interface an
> abstract class or vice versa.)
>
> Regarding 3 and 8, the primary problems are that it's often hard to come
> up with meaningful names that do not conflict with concrete
> implementations, and that for non-native English speakers, this latter
> problem becomes an even bigger obstacle. Additionally, you can't
> determine which files contain abstract classes and/or interfaces just by
> the filename -- you have to look in the file or look in API
> documentation to determine this information.
>
> Now, as to the issues I've seen: the word "Interface" becomes a real
> pain to type (yes, even with autocompletion), and it doesn't really
> connote any real information. When type-hinting, I simply know what type
> I want to use -- the name doesn't need to tell me it's an interface, as
> I already know that information. If I'm writing code that consumes or
> interacts with the class, API docs will tell me what I need to do.
>
> That said, I don't use Abstract classes that often, but considering they
> are a foundation on which to build concrete classes (presumably to take
> care of many of the nitty gritty details and leave the concrete classes
> to implement specifics), I don't mind using a class suffix. "Abstract"
> feels like Hungarian notation, though.
>
> Based on my experiences writing code, I'm currently recommending that we
> do the following:
>
>  3. Use adjective/noun names for Interfaces such as "Foobarable",
>     "Foobarist"
>  7. Suffix abstract classes with "Base" ("FoobarableBase")
>
> The above solve most issues - names are reasonably sized, don't smack of
> Hungarian Notation (okay, so the "Base" verbiage kind of does), and are,
> most importantly, meaningful. Since we already implement code review for
> any code coming into trunk, I think we can even solve the issues for
> non-native speakers as well.
>
> Thoughts? Votes?
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Ralph Schindler-2
In reply to this post by weierophinney
Hi all-

My 2cents.

> When we made the decisions before, we were looking at the following
> three options for interfaces:
>  2. Suffix interfaces with "Interface" ("FoobarInterface")
>  3. Use adjective/noun names such as "Foobarable", "Foobarist"

A mixture of 2 and 3 are the best options IMO.

In some cases, interfaces represent a way of marking a class (Marker
interface) with a specific *capability*.  For example, an object that is
capable of being serialized, or perhaps an object that is capable of
being counted.  In these cases, it makes sense to go with the naming
convention of #3.

On the other hand, and more commonly in OO programing.. You define an
interface that is a contract.  By definition, a contract is a noun, not
an adjective.  In these cases, it makes more sense to go with naming
number 2.

For follow-up reasoning on why compound names are important see my email
(to be posted) on using nouns and adjective-noun combinations for class
names.

> For abstract classes, we looked at:
>  5. Suffix abstract classes with "Abstract" ("FoobarAbstract")

I would play on number 5 as a better choice, but not completely.  Going
with the *adjective-noun* paradigm, I think class names that represent
abstract functionality *should* be in the class name.  I'd opt for
Abstract as a prefix, let me explain why.

There is the added side benefit of all abstract classes bubbling up to
the top of a directory list, and/or being grouped together.

But more importantly, it follows the adjective-noun naming.  For
example: Zend\Filter\AbstractFilter or Zend\Controller\AbstractController.

Why force "ControllerAbstract" when "AbstractController" is more natural
  in English speech?  Think about the two sentences (I know being an
english speaker is not a weighted argument, but all of the code written
in ZF is in english anyway):

"I am talking about the abstract controller."

"I am talking about the controller abstract."

Which has more meaning?

Those names are meaningful, and simply by reading the class, you are
given a wealth of information about what the intentions of that class
are.  In addition, it follows a natural naming convention (in english)
that is easy to replicate across the entire framework of classes.

Thoughts?
Ralph

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Giorgio Sironi
In reply to this post by Lukas Köll
On Mon, Mar 15, 2010 at 11:09 PM, Lukas Köll <[hidden email]> wrote:
> For Zend_Acl_Role I would have thought that Zend_Acl_Role should be the new Interface, while for the default implementation there should be something like Zend_Acl_Role_Default/Text. As I have never needed to implement custom acl-roles myself I also don't know which possible use cases a custom implementation of a Zend_Acl_Role Interface might have. I also think that an interface named Zend_Acl_Role is much more reader-friendly than Zend_Acl_Role_Interface.
> Zend_Captcha_Adapter might from my point of view stay just as-is (because, actually, everything that implements Zend_Captcha_Adapter CAN ACT AS an adapter), Zend_Pdf_ElementFactory_Interface should in my opinion also be renamed to Zend_Pdf_ElementFactory and move the default implementation to something like Zend_Pdf_ElementFactory_Default (maybe someone can come up with something better then "Default" ?) - again, reading "instanceof Zend_Pdf_ElementFactory" feels at least to me much more natural than "instanceof Zend_Pdf_ElementFactory_Interface"

Completely agree.

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

Reply | Threaded
Open this post in threaded view
|

Re: Poll: Interfaces/Abstract class naming conventions

Giorgio Sironi
In reply to this post by Ralph Schindler-2
On Tue, Mar 16, 2010 at 7:25 AM, Ralph Schindler
<[hidden email]> wrote:
> But more importantly, it follows the adjective-noun naming.  For example:
> Zend\Filter\AbstractFilter or Zend\Controller\AbstractController.
>
> Why force "ControllerAbstract" when "AbstractController" is more natural  in
> English speech?  Think about the two sentences (I know being an english
> speaker is not a weighted argument, but all of the code written in ZF is in
> english anyway):

Imho Abstract as a prefix is more readable. I guess it was a suffix
originally because of the logical location of the file:
Zend_View_Abstract goes in Zend/View folder. Instead of contrapting it
to ViewAbstract, a meaningful name can be Zend\View\AbstractView.

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

12