Re: Subject/Observer design pattern in PEAR

Hans L wrote:

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.

Although PHP5 is great for interfaces, this could work just as well for PHP4 packages... Of course the interpreter wouldn't complain as with "implements"... My example was just, well, an example... It doesn't need to be a package on its own, although maybe that could help as easy cut/paste code when the package is already extending another class.

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.

+1 <snip>

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.

Agreed. I remember asking the same thing a while back about a repository for interfaces... for templates among other things... http://marc.theaimsgroup.com/?l=pear-dev&m=108397248417921&w=2 -Philippe