Re: [boost] Re: about function.hpp

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-05-08 10:01:01

On Tuesday 08 May 2001 10:14 am, you wrote:
> --- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> > On Monday 07 May 2001 08:45 pm, you wrote:
> > Here's what I've been considering:
> >
> > function is:
> > 	- Assignment from any target function object
> > 	- Clearing out the value (assignment from nil)
> > 	- Execution of that target function object
> > 	- A check to see if it is empty
> >
> > callback extends function:
> > 	- Equality test
> >
> > signal is a distinct function-like concept:
> > 	- support for multiple slots
> > 	- notification to slot when it dies
> > 	- method of combining multiple return values
> >
> > slot extends function:
> > 	- knowledge of which signals it points to
> > 	- notification to those signals when it dies
> > 	- picks up notification of signal death
> >
> > 	Doug
>
> I'm still not sold on the need for equality testing, and thus don't
> know for sure if 'callback' is needed (How can you compare two
> function objects that are not simple function pointer wrappers? If
> they are this simple, why do you need the higher level wrapper?).
> That said, I think the above descriptions are wonderful descriptions
> of the types we've seen in this discussion.

I'm (obviously) not convinced about equality tests either, and my inclination 
is to forward with 'function' without them and then gauge whether or not 
'callback' is necessary.

> I'm not sure I'd say "signal is a distinct function-like concept" but
> would say that it extends function as well.  A signal fullfills all
> the same requirements as a function concept even though the
> implementation is going to have to be quite different and extra
> functionality is included.

A signal's implementation will be distinct from function, but the signal 
concept is a refinement of the function concept. 

> I'd love to see signals/slots included with function at some point,
> as they will likely be able to share a lot of the same detail
> implementation and should fully cover all "callback" needs.
>
> Bill Kempf

        Doug