Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-30 15:35:35

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <v03110700b64b3a95a629@[153.32.222.4]>, Jesse Jones
> <jejones_at_a...> 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?

A callback that's a closure (wraps both an object instance and a 
member function pointer) has the object as part of the state.  So, if 
the member function modifies the object in any way (VERY likely) then 
it's by proxy (for lack of better terminology) modified the state of 
the function object as well.  I'd agree that such closures are a very 
large percentage of function objects that I use in my own coding.

> 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.

I'm not sure how a delayed function object (which is what we're 
building here) would be "geared" towards STL algorithms.  They all do 
immediate invocation, not delayed invocation.

In any event, I agree that we should stop using the term "callback" 
since this concept is more widely applicable, but I've not heard any 
suggestions for what to call it instead that would accurately 
describe what it is.  So, until such a term is proposed I don't think 
it's that bad to mix various other terms, including "callback", since 
we all know what we mean here.  I don't think the danger of narrowing 
our viewpoint is that great.  Most of us have not limited things 
to "event notification".  In fact, the original impetus that started 
this discussion came from me and dealt with a need for a "generic" 
callback mechanism for thread invocation.
 
> 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.

I'm not sure I follow this.  Taken at face value here I'd have to 
disagree with you because this is a very specific class of function 
objects, aka a polymorphic function object used to wrap generic 
function objects for use in code that can't be rely on template 
typing.  As such I don't know if ref-counting semantics aren't 
appropriate.

Bill Kempf