Re: Interface naming standards?

On Jun 1, 2006, at 1:42 PM, Stefano F. Rausch wrote:

Hi Joe, I wasn't aware of the fact that there are such strict "rules" in place. Are they? I believe Joe was referring to common practices in PEAR. Obviously these aren't hard and fast rules, merely observations based on what a plurality of packages use.

However, and if you don't mind, I would like to ask the following question: What are abstract classes and interfaces useful for? At the conceptual level, abstract classes are placeholders for other classes - classes that implement specifics of the *concept* the abstract class represents. This enables us to treat this set of related classes as _one concept_, for they do represent a particular type of related behavior, read: "concrete classes" are specific or non changing implementations. Interfaces are identical to abstract classes, with the only difference that they provide a specification and no implementation (default behavior). Both can't be instantiated. However and in contrast to abstract classes, one can implement as many interfaces as the design suggests. Now, if I would follow the lines that you've detailed out, how should one define abstract classes? Always as ..._Common? This is just another name for ..._Abstract[Class] and wouldn't - per se - be consistent with your proposal to define interfaces in future as ..._Interface. Interfaces and abstract classes are not identical, and shouldn't be treated that way. Your argument seems to hinge on them being "similar enough" that they should be treated the same. I disagree with your premise, and feel that raising the matter derails the conversation.

To make a long story short: I'm fine with the fact that on a package level every (lead) developer defines his approach, as long as the "usage" is consistent. Great! However, I wouldn't vote a +1 for setting up such "restrictions" PEAR-wide. I feel that this is a namespacing issue, same as class hierarchy is defined by CS, and as such, there should be a clear standard to follow.

As for my opinion on the matter, I'm in favor of: - Foo_Bar. I feel that Foo_Bar_Interface, while clearer in some cases, is duplication of information. Interfaces are really only going to be useful to people extending the package, and they'll need to look at the interface source to see what methods they need to implement anyways. - Foo_Bar_Interface would be my second choice. - Foo_iBar is semantically useless as well as an organizational nightmare, and should be avoided.