Moshe Zadka wrote:
in which way is "harder to use in all common cases" better?
I'm not sure I agree this is harder to use in all common cases, but YMMV. Strings are prone to collisions, etc.
not sure what you're talking about here, so I suppose we're talking past each other. what I mean is that: model.addobserver(view.notify) model.removeobserver(view.notify) works just fine without any cookies. having to do: view.cookie = model.addobserver(view.notify) model.removeobserver(view.cookie) is definitely no improvement. and if you have an extraordinary case (like a function pointer extracted from an object returned from a factory function), you just have to assign the function pointer to a local variable: self.callback = strangefunction().notify model.addobserver(self.callback) model.removeobserver(self.callback) in this case, you would probably keep a pointer to the object returned by the function anyway: self.viewer = getviewer() model.addobserver(viewer.notify) model.removeobserver(viewer.notify)
And usually the code which connects the callback is pretty close (flow-control wise) to the code that would disconnect. FWIW, the Gtk+ signal mechanism has 3-4 different disconnects, and it might not be a bad idea, now that I think of it.
you really hate keeping things as simple as possible, don't you? ;-) what are these 3-4 "disconnects" doing?
as for the "break" functionality, I'm not sure it really belongs in a basic observer class (in GOF terms, that's ^^^ TLA overload! What's GOF?
http://www.hillside.net/patterns/DPBook/GOF.html
a "chain of responsibility"). but if it does, I sure prefer an exception over a magic return value.
I don't know if it belongs or not, but I do know that it is sometimes needed, and is very hard and ugly to simulate otherwise. That's one FAQ I don't want to answer <wink>
yeah, but the two patterns have different uses. </F>