Re: [boost] Re: Callbacks Again

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-17 17:30:45

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

mem_fun won't quite cut it. For a method call it requires that the object
be passed in as you call the callback. This means that you can't call
arbitrary callbacks from non-template code. Very bad.

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

Hickey's original library included ordering, but I've never used it. I'm
not sure I've even used equality tests although that seems more useful.

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

Yep

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

The standard library isn't good enough because it's highly desirable to
call the callbacks from non-template code. I'm not sure about the LL, but
one obvious objection is that it's less portable than some bind functions
targeted at just callback objects.

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

OK, I'll upload something to the vault later tonight.

  -- Jesse