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
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
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.
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
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
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:
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