Re: [boost] Re: New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-30 14:24:28

In message <v03110700b64b3a95a629@[153.32.222.4]>, Jesse Jones
<jejones_at_[hidden]> writes
>>Some, but certainly not the major part. Function objects fall into three
>>categories wrt state:
>>
>>(1) Stateless, eg functions, many of the function object types in the
>>standard, many predicates, many transformations.
>>
>>(2) Stateful but with fixed state, eg many bound function objects, many
>>of the other function object types in the library, many predicates, many
>>transformations.
>>
>>(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?

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. For
instance, there are many uses of this class with regular STL algorithms,
and it is the original reason I wrote the family of classes I did.
Support for event notification was certainly in my mind, but it was not
the sole reason I developed it.

As an aside, if you take this from a function object perspective then
proper copying semantics are the ones that make immediate sense. The
question of reference counting for sharing semantics becomes unasked.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________