Re: Callbacks Again

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-17 09:39:14

--- In boost_at_[hidden], Jesse Jones <jejones_at_a...> wrote:
> >So... before we discuss the thread specific stuff I'd like to first
> >address callbacks.  I've read all the articles on the subject that 
I
> >can get my hands on and it seems they all take different approaches
> >(the Kubrick article covers several of them), each with varying 
pros
> >and cons.  I'd like to describe what requirements I think our 
version
> >of callbacks need to take just to make sure everyone agrees with my
> >opinions before we attempt to create an actual implementation.
> >
> >1.  Need to allow traditional functor types as the callback so that
> >function pointers, standard functors, hand coded functors and 
Lambda
> >Library style functors can all be used with relative ease.
> 
> I'd go with allowing callbacks to be constructed with either a 
functor or
> an object/member function pointer. The second is probably 
redundant, but
> it's such a common operation that it should be very easy to do.

mem_fun, LL et. al. take care of the object/member function pointer, 
so it's redundant IMHO.

> >3.  Copying a callback should be quick, on par with copying a
> >function pointer.  This is not gauranteed with functors but becomes
> >somewhat important with callbacks that may be stored, copied and
> >passed around frequently in some cases.
> 
> We probably also want to be able to test for equality. Possibly 
ordering as
> well.

Hmmm... interesting idea, but I'm not so sure about that.  You can't 
compare functors created with the standard library, for instance.  
And ordering makes little sense, unless it's a partial ordering, like 
that provided by std::type_info.  Comparison and ordering are going 
to be hard nuts to crack here given that standard functors don't 
support this.
 
> >4.  A callback should itself be a functor.
> 
> Along the same lines it's very useful to be able to bind one or more
> arguments. This is pretty easy to do even without a full blown 
lambda
> library.

It's outside of the callback concept, however.  Binding just results 
in a new functor that wraps the original.  It's best handled by other 
libraries such as the standard library and LL, since such libraries 
can do a better job of addressing the issue than we're likely to do 
in this specialized case.

> >5.  Compiler type coercion should be possible to apply to the 
functor
> >that the callback wraps for all parameters and the return value.
> 
> This is also very useful. It lets you do things like assign to a 
callback
> that takes an int argument a function that takes either an int or a 
long.
> Or, alternatively, you can assign a function with two arguments to a
> callback with one if the second argument has a default value.

Exactly.  Doesn't cover all the bases but it covers enough to allow 
the useage to be more robust.  LL and other libraries can then take 
care of the corner cases.
 
> Along the same lines it's useful to assign a function that returns 
a value
> to a callback that returns void.

Which will be a frequent "coercion".  The specializations for void 
returns should make this trivial, so I didn't think to mention it, 
but for completeness sake this should be added to my list.

> >Do you agree or disagree with any of the above?  What other
> >requirements should there be?  Any other ideas or comments?  Is 
there
> >someone interested in submitting an implementation for Boost?
> 
> I can submit some code that fulfills all of the goals you mentioned 
as well
> as the ones I listed above.

I'd appreciate it.  Even if others think we need more thought before 
finalizing this, it's a concept that I think is needed sooner than 
later in Boost so it's time we started looking at real world 
implementations and discussing the theories/particulars.

Bill Kempf