Re: Subject/Observer design pattern in PEAR

Interfaces AFAIK where designed to enable you to implement a standard API that an application will accept eg. function addObserver(PEAR_Exception_IObserver $o) { } However, using them to encourage/enforce coding standards seems a pretty big overhead on a scripting lanuage. It tends to wander off from the aim of providing reasonably independant packages, with minimal dependancies. It may be better that Packages design in their own Interfaces, and over time they could be promoted to PEAR_I* interfaces, eg. rather than designing theoretical Interfaces, then Cherry pick from existing packages later on.. It is also worth considering that some classes (eg. templates) are very performance sensitive. So adding extra overheads is always a serious issue. (obviously this is less true with other classes that depend on slower resources - databases, network sockets etc.) Regards Alan Hans Lellelid wrote:

Jon Parise wrote:

On Wed, Jul 21, 2004 at 06:50:11PM -0400, Hans Lellelid wrote:

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

Instead of enforcing this kind of thing at a coding standard -level, I'd suggest creating a new "Interfaces" category which includes a set of packages that do nothing other than define an interface for a specific pattern or use case. That way, the developer is free to use an existing "standard" interface or roll their own if they feel it's necessary. This also makes it easy to track dependencies and interface adoption. Granted, this really only makes sense for PHP5, but maybe this "standard" should only apply to PHP5 where interface actually make sense.

This sounds very reasonable. Someone just needs to write an RFC, I guess :) I wish I had time. I'm needing to do some more work on Exception RFC as it is, and promised Greg to help out with some error stuff too (plus trying to manage Propel release + full-time job), so I can't volunteer for that. I think some interfaces need to be the product of people with existing packages -- like template interface. They also should be the driven by consensus, because if package writers don't like them they're not going to use them & the whole point is defeated. I also definitely think they shoudl be organically driven -- that is, I don't think that interface should be created in abstract and then imposed on packages after the fact. Interfaces without implementing packages don't make any sense & are likely to be just wrong (and for interfaces fixing things later is clearly a much bigger deal than for packages). There are certainly many things to be decided for interfaces, though. They should have their own very stringent BC rules, probabaly. And naming conventions ... ITemplate, TemplateIface, IntTemplate, Template ...? etc. How they releate to packages -- in terms of namespace, anyway, ... etc. Hans

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com