Re: [boost] Signals Review

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-02-27 10:10:28

On Tuesday 26 February 2002 12:45 pm, you wrote:
> - The terms signal/slot are not intuitive. I know this has been discussed
> earlier, so this is just to say that I personally find the terms "callback"
> or "delegate" better. Now, naming debates are not very productive, so I
> hope this won't develop into a big naming fight.

I don't really have any attachment to the name "signal", it's just that I 
haven't found a short term that describes the behavior well. I've considered: 
callback, event, signal, publisher, producer, and probably others I can't 
remember. The first doesn't capture the multi-target nature, the second 
doesn't include the notion of return values, and the latter two aren't 
general enough. "signal" is of course bad from the Unix point of view, and it 
was chosen only because "signals & slots" is well-known terminology for this 
sort of behavior. 

> Allow me to say that I can
> live with "signal", but I would be happier if the word "slot" was not used.
> As I understood the documentation, a slot is nothing more than a function,
> so maybe we can do without introducing this non-intuitive term at all, and
> just use "function" instead?

I think we can do without the term "slot", but we do need several distinct 
(but closely related) terms:
  1) a term to represent the "target" of a signal invocation as an 
abstraction (i.e., the function object concept), which is now loosely called 
a "slot" or just a "function object"
  2) a term to represent the type used to store one of the (1)'s. this is 
called the "slot function type" and is essentially the type that manages all 
of the nitty-gritty callback details.
  3) a term to represent the type that stores a (2) with the bindings, so 
that it can be safely connected at a later time. This is currently called the 
"slot type" for a signal.

I could see using:
  1) "function object"
  2) "callback type"
  3a) "bound callback type" (?)
  3b) "tracked callback type" (?)

> - The tutorial has a demanding structure. We have a bunch of concepts A, B
> and C. For each concept, we have different kinds of each, A1 and A2. The
> tutorial presents the system in a sequence like A1, A2, B1, B2, C1, C2. I
> would prefer a sequence like A1, B1, C1, A2, B2, C2. This way, I think it
> will be easier to understand why you need A1 and A2, and what the whole
> thing is about.

I see what you mean - I tried to put all of the information for each concept 
into one bunch, and the result is rather confusing. Thank you.

        Doug