Re: Subject/Observer design pattern in PEAR

Hans Lellelid wrote:

Philippe Jausions wrote:

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"...

Yeah, I don't really see how this would work with PHP4. You would have to have a class extend your interface (i.e. class w/ empty methods) which will certainly not be possible all of the time: there will be conflicts in class hieriarchy design in PHP4 when you want a particular component to extend an interface *and* a package-specific abstract superclass. Plus, yes, you have no way of actually enforcing the interface. You could return PEAR_Error from any non-implemented methods, but that might only be discovered at runtime creating more buggy code & not less. I think this may as well be a PHP5 feature of PEAR. Sure, PHP4 packages could conform to the interface, but it would be more of a "gentleman's agreement" (like private vars). The interfaces themselves may as well be written as proper PHP5 interfaces.

My example was just, well, an example... It doesn't need to be aa package on its own, although maybe that could help as easy cut/paste code when the package is already extending another class.

Well, I'm not sure interfaces should be a package, but there should be a way to add core interfaces to PEAR. They would sort of correspond to packages. Ideally everyone with a template engine could sit down and agree on some methods that describe a generic Template class. Then the different template engines could choose to implement that interface in their next releases. The basic idea is that it gives package developers a choice -- albeit a very attractice choice (i.e. why wouldn't anyone want their package to be maximally useful to other PEAR packages & the PHP public in general). It also allows for competition within PEAR without sacrificing interoperability -- as I gather interoperability concerns is the reason why competing packages aren't allowed. 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

Yeah, I remember that too. I think that for templates it is particularly useful, because a single uber-Template is going to lose the things that make the individual engines attractive to people. I think that interfaces allow for a useful distinction between users of PEAR classes and PEAR package developers. Users often want cool new features while dependent package developers want a consistent, reliable API. Interfaces allows classes to be cool & different while being reliable in basic ways. I'm not really trying to convince anyone, as I think probably everyone agrees at some level with this idea :) I guess the question is just how to best propose or negotiate these interfaces. I imagine someone from PEAR Group may have a suggestion ... Hans

I agree with everything. The bottom line is: How do we get Interfaces in PEAR??? I think it's very desirable to have a repository of interfaces otherwise the whole advantage is lost. What would be the point of having incompatible interfaces... ;-) Since PHP5 is so new, it maybe the chance for PEAR to actually come on top of other "scripts" repositories and be seen as a more open community as it is currently perceived... -Philippe