Re: Interface naming standards?

Hi Ian,

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.

Yes, it seems that I've putted too much weight in what Joe wrote.

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.

Please be aware of the fact that object-oriented design captures all *three* perspectives, being (1) the conceptual, (2) the specification and (3) the implementation perspective. One has always to keep these aspects in mind. Hence, on a conceptual level they are identical! On the implementation level they differ. It's that simple, for it doesn't matter how you represent the concept. Just a matter of design choice/constraint. So there's no derailing of the conversation and no simplified approach subject-wise - only thoughts going one step further (regarding the traditional OOP approach) to be considered.

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.

I'm not with you in this respect, definitely not. The standard to follow should be defined by the package lead and not at PEAR "level". -- Stefano Ian Eure wrote:

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.