Re: Interface naming standards?

Hi ...

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.

Convoluted, premise flawed, conclusion incorrect ... ? Are you asking for more clarification? ... artificially narrow view ... ? Narrow? I didn't know that talking about 3 (in words: three) design perspectives to look at at the same time while "coding" does mean narrow. Thanks for the enlightenment. May I suggest that you have amongst others a look at "Design Patterns Explained" - A New Perspective on Object-Oriented Design by Alan Shalloway and James R. Trott - Second Edition, if you don't mind? But I'm sure that it will most probably be as you "say" that I really have totally misunderstood the contents of the book, which - IMHO - is an excellent one. Again: I'm not stating that on the *implementation level* abstract classes and interfaces are identical. I'm far from that and I'm aware of the fact what they should be used for!

The end result is: classes have a predictable, consistent name and location, which makes working with them much easier

Correct you are.

than if the package lead decided to name and lay them out however they like.

Where exactly do you see the potential conflict, or should I say the problem, for one package using e.g. Category_Package_StateEdit[_]Interface and the other defining Category_Package_StateEditable? At the end of the day it boils down to a good documentation and (the mandatory) *consistent usage within the package* itself.

Can you give a reasoned argument as to why you feel that interfaces should be wholly defined by the package lead?

Maybe, because I've a more flexible and differentiated view of interfaces and abstract classes and hence I do use a different - from my personal standpoint and package-wise more logical - naming scheme? There are nor hard feeling Ian. I'm really enjoying the discussion. -- Stefano Ian Eure wrote:

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? --PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php