Re: Subject/Observer design pattern in PEAR

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