Re: [boost] [announce] Multi signature boost::function v1.0

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2008-05-17 01:39:21

On Fri, May 16, 2008 at 9:03 PM, Daniel Walker
<daniel.j.walker_at_[hidden]> wrote:
>
> It's still a vector of signatures. There are two kinds of signature
> here (by convention or protocol):
>
> * int(int, int) is the usual C/C++ call signature
> * plus(_1,_1) is our new emerging polymorphic signature by convention
>

Ok, now I understand, thanks, but still there is a fundamental
difference between int(int, int) and plus(_1,_1), namely the first
it's just an interface but the latter does real work, actually adds
stuff.

I try to explain myself better with an example starting from the
normal functions case:

int add(int a, int b) { return a + b; }
int sub(int a, int b) { return a - b; }
bool is_positive(int a) { return a > 0; }
bool is_negative(int a) { return a < 0; }

msf::function<mpl::vector<int(int, int), bool(int)> > f(add, is_positive);

assert( f(3, 2) == 5);
assert( f(6) == true );

f = sub;
f = is_negative;

assert ( f(3, 2) == 1 );
assert( f(6) == false );

Ok. Simple. Now extend to polymorphic case:

struct add
{
    template<class T> T operator()(T a, T b) { return a + b; }
};

struct minus
{
    template<class T> T operator()(T a, T b) { return a - b; }
};

struct is_positive
{
    template<class T> bool operator()(T a) { return a > 0; }
};

struct is_negative
{
    template<class T> bool operator()(T a) { return a < 0; }
};

Now what I would expect for this generalization is:

msf::function<mpl::vector<_1(_1, _1), bool(_1)> > f(plus, is_positive);

assert( f(3, 2) == 5);
assert( f(3.5, 2.5) == 6.0);

assert( f(6) == true );
assert( f(6.7) == true );

f = minus;
f = is_negative;

assert ( f(3, 2) == 1 );
assert ( f(3.5, 2.5) == 1 );

assert( f(6) == false );
assert( f(6.7) == false );

So here we have:

msf::function<mpl::vector<_1(_1, _1), bool(_1)> >

not

msf::function<mpl::vector<plus(_1, _1), is_positive(_1)> >

because the vector of function signatures define the interface that
function should have to be wrapped by the overload set, as you prefer
to call it ;-), so also in polymorphic case the vector should keep
"polymorphic signatures" that different polymorphic classes with the
proper polymorphic signature should match to be _wrapped_ by the
overload set, not to be the underlying function, replacing
boost::function as you suggested.

In this case boost::function should be replaced by a wrapper of
polymorphic functors, not by _a_ polymorphic functor defined in
mpl::vector at msf::function instantiation.

Am I missing something?

BTW I don't even figure up how this wrapper of poly objects looks like
! or if it even exist.

>> This is _really_ totally different also from an implementation point
>> of view. Indeed a MSF boils down to a hierarchy of operator=() each
>> one defined on a given signature and each one forwarding to a
>> corresponding boost::function
>
> I started looking more closely at your implementation, and I like the
> way you do the class hierarchy. But the important part here is the
> hierarchy of operator()s right?

Yes. I meant that. It was a silly typo, I meant " a hierarchy of operator()"

>  This won't compile yet, but the change I'm think of
> (starting from the msf_27_4_2008.zip version) would be something like
>

This is very old, now is out msf-1.1.zip and in few hours it will be
out msf-1.2.zip with the improved interface for poly objects, namely
the remove of set_polymorphic_object() and use of operator=() instead.

I suggest to download one of the above because they are very different
from the version you have.

>
> I'm sure there's more to it, but that gives you an idea. Of course,
> the first thing you need is an nary version of polymorphic_function.
> If you're serious about this and that's the direction you'd like to go
> in, I'd be glad to start working on it tomorrow!
>

Great!! I'm very interested in polymorphic generalization too, but I
would think is difficult stuff, too difficult for me alone ;-)

Marco