|
Boost : |
From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-30 18:38:56
>>>(3) Stateful but with changeable state, eg RNGs, accumulators.
>>>
>>>In my experience, category (1) and (2) cover most of the uses, eg the
>>>callback examples cited, predicates, etc would fall into these
>>>categories, hence no need for synchronisation. Category (3) is the
>>>minority category, IME, and it is only category (3) that definitely
>>>requires synchronisation.
>>
>>Callbacks that wrap member functions also generally fall into category 3. I
>>think that will be the most common use of callbacks. They're very handy for
>>GUI programming and other sorts of notifications. The other categories seem
>>most useful with template programming (eg std::transform), but I don't
>>think most people now or in the medium term will use callbacks much there.
>
>Perhaps you misunderstood the classification. Most callbacks fall into
>category 2: stateful but with fixed state. In what way does the function
>object associated with typical callbacks normally change? It has a
>target, a member function to hit, and something to say. I would presume
>that this would not change once the callback had been invoked. What
>state changes in the callback did you have in mind?
Well, I was thinking of state in a broader sense than that in just the
callback object. However the only way to protect that state seem icky so I
think your original narrowly focused definitons are right.
>As another point, no matter what terminology we settle on eventually, I
>think we should consider dropping "callback": this is an application of
>the class under discussion not its sole use or only reason for
>existence. I think the name has strongly coloured the way that people
>have considered the class, ie geared towards event notification.
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
addressing.
-- Jesse
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk