Re: Interface naming standards?

On Jun 9, 2006, at 10:37 AM, Stefano F. Rausch 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. Your argument is convoluted, your premise flawed, and your conclusion incorrect. They are the same only if you adopt the artificially narrow view you put forward.

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

- PEAR defines a base class name hierarchy (HTML_Foo, DB_Bar, XML_Baz, etc) which (with a few exceptions, such as Var_Dump, PHPDoc, and Inline_C) all class names descend from. - PEAR defines a filesystem layout based on those class names. The end result is: classes have a predictable, consistent name and location, which makes working with them much easier than if the package lead decided to name and lay them out however they like. It is my opinion that interfaces are (or could be) a common enough occurrence that the benefits from having a consistent naming scheme would be significant, and that we should have them standardized for that reason. I am not proposing that we be totalitarian about it; if there is a reasonable argument as to why one package should be excepted, I am fine with discussing that and voting. This is precisely what happened with my Net_SMPP package. I believe that if we leave interface standards up to individual developers, we will end up with a lot of inconsistent interface usage, for no good reason. If we follow some sort of standard (not necessarily the one I support), we have consistency, unless there is a valid, reasoned argument as to why a package should be exceptional. Can you give a reasoned argument as to why you feel that interfaces should be wholly defined by the package lead?