Re: Re: Subject/Observer design pattern in PEAR

Michael Wallner wrote: > Uhm... > > Why this "Util" prefix? Why not? 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.... > If you'd use ClassHints you could strip most of the throw > statements. Absolutely, but then I'd end up with a fatal error, which might not be the perfect solution either. (Is it possible to downgrade the 'Argument X must be an instance of Y in ...' error level to a warning somehow?) > 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! Should one design a completely new class, which implements the observable interface, why should one do the complete implementation from scratch in stead of extending a common base class? > 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); > } And isn't that exactly what the proposed base interface implements? There are however quite a lot of *commonly used* implementations of the observable pattern (e.g. should it be the observer or the observable, who filters ignored notifications?), and that's exactly what I'm trying to target here. As for the method names feel absolutely free to dislike my using the same method names *commonly used* in Java... > Sorry, but over all I'm not very happy with this implementation. It's the interface that matters, not the implementation! Regards, Heino