From: Douglas Gregor (gregod_at_[hidden])
Date: 2000-12-01 19:33:44
On Fri, 1 Dec 2000 16:15:58 -0800
Jesse Jones <jejones_at_[hidden]> wrote:
> >In message <email@example.com>, Jesse Jones
> ><jejones_at_[hidden]> writes
> >>Callback doesn't mean event notification to me or, I think, many people. It
> >>means deferred function call which is exactly exactly the concept we're
> >Yes, the meaning of deferred call is the original one, but I have
> >noticed a slow shift towards more specialised use in recent years, eg
> >I don't know how much of the specialisation in vocab is related to the
> >rise of event-driven architectures, but in common use it is no longer as
> >general or unambiguous as it used to be.
> That may be true, but the name callback still means something close to
> "deferred function call" for a broad audience which is helpful.
> >For STL function objects, I
> >note that many users do not immediately think of them as callbacks
> >although, strictly speaking, they are.
> >So, I think that the use of the term callback is not as clear as you
> >might have hoped, and we should -- as library authors -- be aware of and
> >sensitive to that.
> So, what's a better name? signal? event? function_ptr? I think the first
> two are clearly worse names. function_ptr is almost a good name, but I
> suspect Joe Average developer will prefer callback.
I think "signal" implies the extra functionality where the destruction of the target (slot) will notify the signal, so "signal" should be reserved for that concept. "Event" is just one use of a callback, IMHO, and not general enough to use for Boost. My preference would be function_ptr if the callbacks have reference semantics, or function_obj if they have cloning semantics ("functor" would be my first choice for cloning semantics because it is concise, but it appears that it is no longer a usable term).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk