On Thu, 20 Apr 2000, Fredrik Lundh wrote:
> > A better way, and more popular (at least in the signal/slot terminology),
> > is to return a cookie on connect, and have disconnect requests by a cookie.
>
> 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. 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.
> 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?
> 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>
--
Moshe Zadka <mzadka@geocities.com>.
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4