# Subject and Observer Interfaces - Thread: https://externals.io/message/18809 - Original archive: https://news-web.php.net/php.internals/18809 - Started by Jeff Moore on 2005-09-13T05:07:47+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #18809 — Jeff Moore — 2005-09-13T05:07:47+00:00 URL: https://externals.io/message/18809#18809 Would it be possible to remove the Subject and Observer interfaces or at least delay them until a later release? The problem with the Observer interface is that any class implementing it is only capable of receiving one kind of notification (update) and there is no capability to send any additional information. The problem with the Subject interface is that it can also only support one kind of observer. Together these are harsh restrictions that would limit the use of these interfaces to only the most trivial applications. These interfaces are fine as a textbook example of the observer pattern, but I don't see them as generally useful enough to have as part of the language. Regards, Jeff Moore --- ## #18810 — Sebastian Bergmann — 2005-09-13T05:35:38+00:00 URL: https://externals.io/message/18809#18810 · In reply to: #18809 Jeff Moore schrieb: > The problem with the Observer interface is that any class implementing > it is only capable of receiving one kind of notification (update) and > there is no capability to send any additional information. > > The problem with the Subject interface is that it can also only support > one kind of observer. You can extend the interfaces interface MySubject extends Subject { } interface MyObserver extends Observer { } and adapt them to your needs while retaining the possibility to use them with other code that only knows about the original Subject and Observer interfaces. -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #18811 — Marcus Boerger — 2005-09-13T05:37:50+00:00 URL: https://externals.io/message/18809#18811 · In reply to: #18809 Hello Jeff, there is no way in implementing multi-whatever observer and subjects typesafe. If you want that you'd end up calling them MySubjectWhatever, MySubjectWhatnot, MySubjectWhatelse, ... and MyObserverWhatever, ... The other thing you mentioned, sending information along, is not necessary because you have access for what you really need, at least you can give the access yourself by your design and i strongly encourage you do so. The only thing that can be usefull sometimes is being able to prevent some observers from being notified. But that would require PHP dealing with optional parameters in its signature checking rules and i must admit that i couldn't get that to work. regards marcus Tuesday, September 13, 2005, 7:07:47 AM, you wrote: > Would it be possible to remove the Subject and Observer interfaces or > at least delay them until a later release? > The problem with the Observer interface is that any class implementing > it is only capable of receiving one kind of notification (update) and > there is no capability to send any additional information. > The problem with the Subject interface is that it can also only support > one kind of observer. > Together these are harsh restrictions that would limit the use of these > interfaces to only the most trivial applications. These interfaces are > fine as a textbook example of the observer pattern, but I don't see > them as generally useful enough to have as part of the language. > Regards, > Jeff Moore Best regards, Marcus --- ## #18830 — Jeff Moore — 2005-09-13T14:42:34+00:00 URL: https://externals.io/message/18809#18830 · In reply to: #18810 > You can extend the interfaces ... > and adapt them to your needs while retaining the possibility to use > them > with other code that only knows about the original Subject and > Observer > interfaces. Actually you can't and still be typesafe. If I extend Observer and add a changed() method, I cannot pass that new object to a standard Subject interface because that interface has no business calling the changed() method since its not on the base Observer interface that it specified. There are other problems. The two interfaces are tightly coupled and extensions are not interoperable and thats why I think they aren't generic enough to be a standard base class in PHP. --- ## #18831 — Jeff Moore — 2005-09-13T15:31:03+00:00 URL: https://externals.io/message/18809#18831 · In reply to: #18811 > there is no way in implementing multi-whatever observer and subjects > typesafe. Java does it. (However, I am most definitely NOT suggesting emulating java's solution in php.) > The other thing you mentioned, sending information along, is not > necessary > because you have access for what you really need, at least you can give > the access yourself by your design and i strongly encourage you do so. Implementation note 6 in the patterns book talks about this, labeling the two styles push and pull. Push is common, too. (for example in PRADO and PEAR.) This interface mandates pull. I'm just suggesting that this particular design for Subject and Observer is not generic. There is more to the observer pattern than these interfaces express. What is the value of defining a standard interface if it can only be used in a fraction of the common cases and impedes extension? I think that if Subject and Observer go into 5.1 as they are now, two or more of the following will happen: Most people won't be able to use them. Many people will waste time trying to use them before finding the limitations. They will have to be extended later in a way that breaks backward compatibility to get around those limitations. A parallel, more capable, more mechanism will be developed and added later. They will have to be deprecated in a future release. Is there a pressing need to have this in 5.1? Why not wait to a later release and address some of the things that people commonly want to do with the observer pattern: Additional notification information (push style). A observer that can receive more than one kind of notification. A subject that can send more than one kind of notification. Regards, Jeff Moore --- ## #18846 — Andi Gutmans — 2005-09-13T22:25:06+00:00 URL: https://externals.io/message/18809#18846 · In reply to: #18831 Did I miss something? Where/when did Subject/Observer interfaces go into PHP 5.1? These are very generic names. Marcus, I checked PHP CVS and suddenly saw you commited something like this. I would question in general the direction you're going with Spl. But in any case, these if anything they should be SplSubject, SplObserver. No way that SPL should be taking such generic names... Andi At 08:31 AM 9/13/2005, Jeff Moore wrote: > > > > […] > >Java does it. (However, I am most definitely NOT suggesting >emulating java's solution in php.) > > > […] > >Implementation note 6 in the patterns book talks about this, >labeling the two styles push and pull. Push is common, too. (for >example in PRADO and PEAR.) This interface mandates pull. I'm just >suggesting that this particular design for Subject and Observer is >not generic. >There is more to the observer pattern than these interfaces express. >What is the value of defining a standard interface if it can only be >used in a fraction of the common cases and impedes extension? > >I think that if Subject and Observer go into 5.1 as they are now, >two or more of the following will happen: > >Most people won't be able to use them. >Many people will waste time trying to use them before finding the limitations. >They will have to be extended later in a way that breaks backward >compatibility to get around those limitations. >A parallel, more capable, more mechanism will be developed and added later. >They will have to be deprecated in a future release. > >Is there a pressing need to have this in 5.1? Why not wait to a >later release and address some of the things that people commonly >want to do with the observer pattern: > >Additional notification information (push style). >A observer that can receive more than one kind of notification. >A subject that can send more than one kind of notification. > >Regards, > >Jeff Moore