Re: Subject/Observer design pattern in PEAR

On Wed, 21 Jul 2004 17:21:35 -0400, Hans L <hans@velum.net> wrote: > Philippe Jausions wrote: > > Klaus Guenther wrote: > > > >> Philippe Jausions wrote: > >> > >>> Hi, > >>> > >>> Just wondering if the PEAR group advised about the member and method > >>> names to be used for the Subject/Observer design pattern? > >>> Apparently there is no consistency in the PEAR packages that use that > >>> pattern. > >> > >> > >> So far, there is no standard naming convention for such things. There > >> was merely the private/public distinction. However, certain names have > >> become established for certain functions (e.g., toHtml, toString, > >> etc.). There certainly would be some benefit in promoting consistency :-) > >> > >> Klaus > > > > > > Just to get the ball rolling then, not that it would necessarily lead to > > something, but wondering what would be the most flexible: > > <snip> > > This should IMO be proposed as a [PHP5] interface. That's what they're > for; obviously PEAR shouldn't care about the internal implementation as > it could well differ for every package that implements this pattern. > Interfaces will make PEAR code very loosely coupled & IMO will be a > great, great thing for PEAR being adopted on a much wider scale AND for > playing a more prominent role in PHP code community. > > I don't know how that should be handled, but there should be a way to > propose core interfaces & then encourage (note: not force) packages to > use them. Packages will use interfaces because it's to their advantage. > > Also interfaces should describe very basic functionality. E.g. a Logger > interface should describe very basic, basic functionality of PEAR::Log > that would be useful to *other packages*. For example, packages > generally don't care about needing to attach listeners to a logger; they > want to know that a log() or err() method exists & that's all. If I > want to write a quick 'n dirty logger, I should just have to implement a > handlful of methods to satisfy any PEAR (or other) library that is built > to use logging. > > Same principle should IMO apply to template engines. Let the different > implementations exist, but provide a basic set of methods in an > interface (e.g. assign(), parse(), display(), etc.). Classes like > QuickForm therefore would only care that the specified template met > basic criteria & it would allow individual template packages to provide > lots of differences in implementation & add-on features that users (but > not other packages) care about -- like caching, filtering, etc. > > Hans > +1 from me. -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--