Re: Status of Util_Observable?

Martin Jansen wrote: >On Sun Jan 16, 2005 at 09:5519AM +0100, Arnaud Limbourg wrote: >> Martin Jansen wrote: >> >Concidering the current Dispatcher proposal I'm wondering if there is >> >still a need for the (apparently stale) Util_Observable proposal? If >> >you guys think that we still need to formalize an interface for >> >observable classes, I'd be happy to revitalize the proposal. >> >> Isn't it redundant with the Event_dispatcher package now ? > >I got that impression, too. But I wanted to make sure that we don't >loose anything valuable. Perhaps Bertrand can tell us his opinion on >whether his proposal supersedes Util_Observable. I think both can co-exist. From GOF pattern book, here is how they describe the motivation behind the Mediator pattern which is used by Event_Dispatcher: "Object-oriented design encourages the distribution of behavior among objects. Such distribution can result in an object structure with many connections between objects; in the worst case, every object ends up knowing about every other. (...) Partitioning a system into many objects generally enhances reusability, but proliferating interconnections between those objects tend to reduce it again." The mediator object solves this problem by encapsulating all interconnections, acting as the hub of communication, being responsible for controlling and coordinating the interactions of its clients, and promoting loose coupling by keeping objects from referring to each other explicitly. Furthermore, Event_Dispatcher offers a few features that makes it more interesting when dealing with notifications, it allows you to filter and cancel them at runtime. Being a mix of both Observer and Mediator, it offers more than just Observer and is in my eyes a lot easier to implement and use in large applications. So I wouldn't say it supersedes Util_Observable, it complements it, maybe making it less useful, but some people might still prefer to deal with observers in each and every classes they make observable (something I doubt on the long run). Packages that comes bundled with concrete observers (none that i know of) might prefer to use Util_Observer. Though, in order to make Event_Dispatcher useful for other PEAR developers, in case they want to use it in their own packages, we have to define a common way to: 1. Document the methods that post notifications. It would be nice if that was supported by PHPDocumentor, like the @throw keyword, maybe something like @post NotificationName. Still, this can also be added directly in the method description. 2. Define a standard way to name notifications posted by PEAR packages in order to avoid collision. Something like : PackageClassName_Notification_EventName Example: HTML_QuickForm_Notification_onSubmit This might become subject to an RFC. Cheers, Bertrand Mansion Mamasam