Re: Interface naming standards?

Hi Joe, I wasn't aware of the fact that there are such strict "rules" in place. Are they? 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. IMHO with the addition of tag Interface/Common (or alternatively Abstract[Class]) tag, you're not really enhancing very much the readability of the code. Sure, there's the hint, but the clue is already in the documentation. Full stop. 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. My 0.02 subject-wise. -- Stefano Joe Stump wrote:

I don't agree with this. The common format for PEAR thus far has been: Spreadsheet_Writer (contains static factory - is abstract) Spreadsheet_Writer_Common (contains *definitions* of common functions - is abstract) Spreadsheet_Writer_Excel (contains Excel implementation) With an interface you'd probably have Common implement Spreadsheet_Writer_Interface and define some of the functions in the Interface. There's definitely scenarios where you'd want a Common class and an Interface. Additionally, very few PEAR packages that implement the factory pattern extend their drivers from the base class, instead relying on a common class. --Joe On Jun 1, 2006, at 11:36 AM, Stefano F. Rausch wrote:

Hi, Is it really necessary to add the tagging word "Interface"? Take for example: Spreadsheet_Writer ---> this is the interface Spreadsheet_Writer_Excel ---> implements the interface ;) Spreadsheet_Writer_OpenOffice Same would apply to abstract classes being extended. Positive side-effect: lesser to type and no naming "pollution". Why make things difficult? A package should always have API docs in place and (hopefully) a sort of manual, where "everything" is explained. Your feelings? -- Stefano Daniel Convissor wrote:

Heya: On Thu, Jun 01, 2006 at 09:38:20AM -0700, Joe Stump wrote:

I'm currently working on a package that I plan on having an interface defined in.

Funny you should mention this. I was thinking about a new pacakge with interfaces too, along these lines: Spreadsheet_Writer_Interface Spreadsheet_Writer_Excel Spreadsheet_Writer_OpenOffice Spreadsheet_Writer_Interface_Workbook Spreadsheet_Writer_Excel_Workbook Spreadsheet_Writer_OpenOffice_Workbook Etc... --Dan

--PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

--PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php