Re: [PEPr] Changes in proposal for Util::Util_Observable

On Fri, 2004-09-17 at 17:56, Philippe Jausions wrote: > Stig S. Bakken wrote: > > On Fri, 2004-09-17 at 02:28, Justin Patrin wrote: > > > >>>Observable_Interface rings a lot better in my ears, the intention is to > >>>make it sound English after all. > >>> > >> > >>But it's not an Interface you can Observe, it's an Interface to make > >>something Observable. Also, Interface is a general category and IMHO > >>should be a prefix for that reason. Class names in PEAR are supposed > >>to go from general to specific. > > > > > > I doubt anyone will misunderstand "Observable_Interface" as "an > > interface you can observe". There is precedence for this format in how > > exception and error classes are named, diverting from that is what would > > cause confusion. > > > > Anyway, "Observable_Interface" cannot be the proper name since it would > require a new top-level "Observable" category... I don't see this > package fitting in an existing category. > > Please check the comments under the proposal before restarting a new > thread of discussion. > > Basically here's a summary: > > - Utils/Observable/Interface.php > - Pattern/Observable/Interface.php > - Interface/Observable.php > > If a new "Interface" category is used, then that prevents an > implementation to be placed there. And yes it would be usefull to have a > package that implements just the interface. On the other hand, an > interface could be implemented by various packages, therefore having an > "Interface" category makes it easy to not confuse the package for the > interface. > Another dowside of a "Interface" category, is the risk to have to > recreate the whole PEAR directory structure under it. > > Some propose to put all the interfaces into one package for convenience. > Doesn't seem very flexible or extensible as new interfaces couldn't be > added individually. > > Some consider a new "Pattern" (or "Coding", "Programming") > category too > "framework" specific, and therefore shouldn't be included in PEAR. > > Basically, should an interface be in the same directory as the main > package implementing it or should it be in a collection of interfaces? > Consistency for all interface is a must, so to help you think consider > the two interfaces: Observable and Template... We're facing two types of interfaces here, one named after its local function in a package (DB_Driver_Interface), and one named by its function-at-large (Template_Interface). The way PEAR is modeled now, only the former fits in directly with the naming scheme. But to get anywhere with interoperability, I think it's a good idea to start establishing function-at-large interfaces (Template_Interface is a bad example, being "equus mortus"). These should probably be provided as separate packages. - Stig