Re: Re: PEAR and interfaces

David Coallier wrote: > On 1/4/07, Gregory Beaver <greg@chiaraquartet.net> wrote: >> David Coallier wrote: >> > Hey all, sorry if this is repeatitive, and if it is please point me to >> > the good documentation but I was wondering if it was ever discussed >> > before. The use of interface and it's structure in pear. >> > >> > MainPackage class: >> > ----------------------- >> > require_once 'Path/MainPackage/interface/MainPackageInterface.php'; >> > class Path_MainPackage implements Path_MainPackage_Interface { } >> > ----------------------- >> > >> > Let me know if this is the good structure used for PEAR or what shoudl >> > be used if it is not. We should use a clear mapping of class/interface names to file names as it makes any (auto)load implementation easier to code and faster to run. >> Hi, >> >> There has been a great deal of debate on how best to do this. I think >> that it may be better to require an I prefix. Why? "Interface" can >> mean more than just the language construct (think of user interface, >> etc.). This means there is actually some unintended ambiguity here. It >> is a recognized practice in other languages to simply prepend I, so that >> we get: >> >> Path/MainPackage/IWhatItDoes.php In my opinion language constructs should have precedence over user defined stuff. This plain 'I' is more confusing: could also be 'Input', 'Internet' or 'iPod'... and for me it only has the smell of lazy coders ;-) I would prefer using Interface as common postfix separated by '_' as it is already used with exception classes, e.g. PEAR2_Registry_Interface PEAR2/Registry/Interface.php If you need to implement an other sort of interface you could use another naming schema, e.g. PEAR2_RegistryInterface PEAR2/RegistryInterface.php or you add information about what interface it is: PEAR2_Registry_Interface_REST PEAR2/Registry/Interface/REST.php I don't agree that there are so many interfaces. > Although what I could see is something along the lines of a general > directory for all the interfaces in pear. A centralized interfaces > directory maybe. > > In the package.xml file we could mention something like > <file role="interface" ..../> > > and it would go to the interfaces folder thus calling it would > automatically be like > > <?php > require_once 'interfaces/NewPackageInterface.php'; > class New_Package implements New_Package_Interface { } > ?> Although it seems to be a nice idea I see many problems with such a concept. For me it's enough to separate packages into 'lib' and 'data'. Code should stay in the package directories - otherwise it would add a further "level of confusion"... Regards, Matthias