Callback-related libraries and terminology
in [C++]
|
Prev: bind guard ?
Next: Sanity check: public/private
From: Jiang on 24 Aug 2006 09:16 Scott Meyers wrote: > > - When a Boost.Signals signal or a .NET delegate is called, it invokes > the callable entities it contains. > > Is that correct? > Well, I believe the word "contains" is too strong to be used here. There is no such a relationship between signal and slot objects. The class/object which emits a signal does not know which slot(s) will receive the signal, also it simply does not care about it. IMHO, "connects" can be used to convey the meaning of loosely coupled relationship between signal and slot. Also I think signal/slot mechanism is slightly different from Delegate. > Also, does anybody know where the name "slot" comes from in this context? > I've found this term to be a stumbling block for trying to understand this > stuff. > IIRC, signal/slot was first purposed by Qt. And it is the key feature which distinguishes Qt from other libraries. Slot is quite a good name, but signal has many other meanings and unnecessary confusion will be introduced (well, if not used together with slot). "plug-slot" is a better choice ? :-) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jiang on 24 Aug 2006 09:19 kanze wrote: > werasm wrote: > > Scott Meyers wrote: > [snip] > > > I would define the signal as the "callable entity" and the > > slot as the "executable entity". The lost exists at the > > execution sight, whereas the signal exists at the callsight. > > I would avoid the word "signal", as it has other meanings in C++ > (and C). What's wrong with the classic terms event or notifier, > Can not agree more. If terminology is an issue, then it is better avoid such kind of wording. Notifier-Observer, or Publisher-Subscriber is much better in my mind. > and handler or callback? > Hmm..., for the same reason, handler and callback should also be avoided. Handler is quite a general word, which can be used for any resouce, such as windows GDI, file, IRQ ... And for callback, usually it means function pointer which will be passed to OS or special function (qsort ...). Compared with Observer, this method is ensentially not type safe and usually introduces tight coupling. > > Slots are basically the callback that gets called in response > > to a signal (event). > > An asynchronous callback, in sum. Or a handler. > By default, the signal/slot works in a synchronized manner, IIRC. The original meaning of signal does not apply here. That is, the emit won't return until all connected slots have returned. > > The mechanism IM(h)O is very similar to GOFS command pattern > > which I personally prefer at this moment. A signal is emitted, > > and all slots bounded to that signal is called, so to speak > > (Macro-command is executed, and all the children bounded to it > > is executed). > > An event forwarding discriminator? > Delegate solves the problems of typesafe directly event dispatching a nd Observer mainly decouple the one-to-many dependency. The functionalites overlap but they are different tools for different purposes. That is why we have both boost.function and boost.signal. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: werasm on 24 Aug 2006 09:20 werasm wrote: > I would define the signal as the "callable entity" and the slot as the > "executable entity". The lost exists at the execution sight, whereas > the signal exists at the callsight. Should read: I would define the signal as the "callable entity" and the slot as the "executable entity" (or callable entities). The [slot] exists at the execution sight, whereas the signal exists at the callsight. Pardon the typo, my fingers are dyslexic, W [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: werasm on 24 Aug 2006 09:22 kanze wrote: > werasm wrote: > > Slots are basically the callback that gets called in response > > to a signal (event). > > An asynchronous callback, in sum. Or a handler. Yes, asynchronous in the sense that the receiver does not know when the sender may make the call, but in that sense all normal functions could also be considered asynchronous. More importantly, the sender need not be bound to a particular receiver (As you know). Synchronous or asynchronous in the sense that the execution of the callback could be in the context (thread/task) of the caller or the context of the receiver. The other thing that may be a consideration, is that the caller need not know whether the call happens synchronous or not. The abstraction is now - we make a call (or we signal a) on a callable entity (perhaps slot) we do not know, and we don't know whether that call will be complete at the next statement of the caller (synchronous or asynchronous). Of course sometimes it is important to know that a call is complete before continuing, but often the purpose of a call is just to indicate (signal) an event and continue with your business without bothering with how and when the event is handled. >> Or a handler. Certainly, yes > > > The mechanism IM(h)O is very similar to GOFS command pattern > > which I personally prefer at this moment. A signal is emitted, > > and all slots bounded to that signal is called, so to speak > > (Macro-command is executed, and all the children bounded to it > > is executed). > > An event forwarding discriminator? Begging my pardon, I'm not really familiar with this term. I gather its from Corba - is it the mechanism that determines (discriminates) whereto events will be routed? In that case, yes. Kind regards, Werner [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Kurt Stege on 24 Aug 2006 09:35
kanze wrote: > werasm wrote: > >>Scott Meyers wrote: > > >>>Also, does anybody know where the name "slot" comes from in >>>this context? >>I think the name "slot" originates from the Qt GUI Framework. >>I would define the signal as the "callable entity" and the >>slot as the "executable entity". The lost exists at the >>execution sight, whereas the signal exists at the callsight. > > > I would avoid the word "signal", as it has other meanings in C++ > (and C). What's wrong with the classic terms event or notifier, > and handler or callback? "Handler" is a worthless term. What is the handler handling? Signals? Events? Messages? Fruits? "Callback" is misleading. The word (and the classic meaning) says: I am calling you now. Please do you call _me_ back sometimes later. The callback idea separates the sender and the receiver of a message in a way that the sender (at compile time) does not know anything about the receiver. However, the receiver knows about the sender for registration purpose. The signal slot idea separates registration from the receiver. The receiver does not have to know anything about the sender, neither in compile time nor in run time. This separation helps to re-use the receiver for other application contexts, just by exchanging the "application" that does the registration (often called "connection" between sender and receiver). >>Slots are basically the callback that gets called in response >>to a signal (event). > > > An asynchronous callback, in sum. Or a handler. See about the term "handler"? You like to name the signal a handler, and now you are naming the slot a handler. I didn't find short and pregnant replacements for the terms signal and slot. Message sender or event receiver might do, but they sound clumsy. I suppose the terms signal and slot are used in a wide area for exactly this purpose, that the danger of confusion with Unix- or C-signals is small. Best regards, Kurt. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |