Re: Interface naming standards?

On Jun 7, 2006, at 5:28 AM, Daniel Convissor wrote:

On Tue, Jun 06, 2006 at 11:14:07PM -0700, Ian Eure wrote:

On Jun 2, 2006, at 8:52 AM, Daniel Convissor wrote:

Spreadsheet_Writer_Excel Spreadsheet_Writer_Function_Excel Spreadsheet_Writer_Format_Excel Spreadsheet_Writer_etc..._Excel Thus, the Excel packge files would be in the Function dir, the Format dir, etc... Total PITA to find things.

Just depends on how you're thinking of it, I suppose. I don't think that the latter is all that terrible, and splitting off the Excel stuff into a subpackage would help as well.

They can not be sub-packages. They are an integral components needed to write spreadsheets: Spreadsheet_Writer_Excel

    the central class for the driver.
    the classes below become properties in this class.

Spreadsheet_Writer_Excel_Format

    processes formatting of cells in the spreadsheet

Spreadsheet_Writer_Excel_Function

    processes writing functions into the spreadsheet

That package will then have a dependency on "Spreadsheet_Writer" which contains static methods needed by all of the spreadsheet drivers, such as factory(). This last aspect causes problems with the naming scheme you proposed in another email in this thread. You proposed Spreadsheet_Writer be the interface. But it can't be. Many packages in PEAR follow the base class / driver layout I'm talking about here (eg: DB, MDB2, etc...) I didn't propose anything specific with regards to S_W, merely that I felt that _Interface wasn't all that helpful and was a duplication of information. I'm not familiar with the structure of S_W, but a rough example would be more akin to:

Spreadsheet_Writer - abstract class, factory(), etc. Spreadsheed_Writer_Format - interface class Spreadsheed_Writer_Format_Excel - concrete class which implements the S_W_Format interface And so on. The base S_W package would contain the abstract base class and interfaces, and subpackages would hold the implementations for different spreadsheets.