Re: Re: Subject/Observer design pattern in PEAR

Hans Lellelid wrote: > I'm glad you jumped up & proposed a package! Well, it was only a matter of doing some cut&paste and remove some code... > > As clearly stated in the proposal description, this code is based on private > > purpose code. I merely choose not to change the unimportant stuff, since I > > really didn't care much in which category the code might end up in.... > > 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. > >>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 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? > >>Even the need to extend a class to implement > >>the observable pattern limits way too much in my opinion. > > > > You wouldn't *have* to extend the class, since you could of cause implement > > the interface in any class - that's the beauty of interfaces, isn't it? The > > class is only meant as a base class, which one could choose to extend or > > not. It's all about the interfaces! > > Yup, this is the design of interfaces. You do have to implement them. > Certainly you don't have to extend any base classes, though. I think the reason this came up was the fact that I also have a base reference Observable class, which *could* be extended... > >>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! Regards, Heino