Re: Re: Subject/Observer design pattern in PEAR

Heino H. Gehlsen wrote:

Hans Lellelid wrote:

Maybe there should be an Iface Category ... ? I don't know how many of these things are really expected. Unlike packages, the more there are the less useful they are, really.

Op perhaps there should simply only be one interface package, Interface or even better PEAR_Interface, which includes one file per category (either in the root or in the PEAR directory). This way mail related interfaces would be found in either /Mail.php or /PEAR/Mail.php and so on.

I would think interfaces should reside under the category that makes the most sense purpose-wise... Why not a new category "Pattern" for the observer... Template interface would be under "Template" (or HTML_Template). Both the interface and an implementation would be useful. Interface because it's the whole idea here and an implementation because it's convenient to not start from scratch sometimes... ;-) This way, an interface would be named something like "Pattern_Observer_Interface", "Pattern_Observable_Interface", "Pattern_Observer_Filtered_Interface" "Pattern_Observer_Note_Interface"... whatever... And the package itself would be "Pattern_Observer"... and so on...

If you'd use ClassHints you could strip most of the throw statements.

I agree -- definitely classhints would be the way to go here. That's really the nice thing about using interfaces with PHP5.

So do I, but I'm not sure if it's time to use them yet. (?)

I would think type hint is the way to go, and since there nothing yet, why not start now properly. I can hear a long long long "battle" over type hints coming in the distance ;-)

I think it's ok for the error to be fatal, because code must implement the interface (no need to extend a base class or anything). The thing that needs improvement is that error itself & that is something for PHP internals folks to improve. (it has come up & there was support for adding a reference to the calling code, so I anticipate that this will get fixed)

So in the near future the scripts won't always have to die on us should we de the unthinkable?

By using type hints you basically don't have to care much about errors here. We shouldn't really care if an observer returns/throws an error upon receiving a notification... Decoupling the interfaces from PEAR "internals" would definitely be a huge plus, otherwise you're just defining an interface for PEAR packages, and leaving the rest of the world out... hardly a useful example of interface, especially for pattern designs.

I'd much more appreciate the commonly used API for observers:

interface Observable { public function attach[Observer](Observer $Observer); public function detach[Observer](Observer $Observer); public function notify($Note); }

While I agree with Michael that the attach/detach/notify seem a lot more prevalent in the observer patterns I've encountered/used, the propsed addObserver-style method names are certainly very clear.

Personally I don't care much wether the methods are called (detach|attach)Observer or (add|delete)Observer, but the notity method should definately be called notifyObservers if the other methods ends with Observer!

As long as the names make sense and are coherent, it doesn't really matter what other languages name them... subscribe, unsubscribe and broadcast could work just as well... If there is an undisputed "bible" for pattern designs I suggest we go by the names they use... -Philippe