Re: [boost] [challenge: Dynamic Overloads]

From: Marco Costalba (mcostalba_at_[hidden])
Date: 2007-10-09 02:41:14

On 10/8/07, Joel de Guzman <joel_at_[hidden]> wrote:
> Marco Costalba wrote:
>
> >> It has the right semantics and is very idiomatic. This is how
> >> Boost.Function does it. Only in this case, we can have many mappings
> >> instead of just one.
> >>
> > I would prefer 'add' or 'assign' here because 'overload' is a kind of
> > a container while fooX are single functions.
> >
> > My intuitive idea of operator=() is that at the end what is at the
> > left is == of what is at the right, in other words:
> >
> > std::string a;
> > a = "apple";  // now I would think 'a' is an apple
> > a = "blueberry"; // now 'a' is *no more* an apple, is a blueberry
> >
> > assert(a=="apple"); // ??? strange last assignement was a bluebarry here!
>
> Assignment can be lossy, you know. Here's a sample:
>
>     int x;
>     x = 0.0001;
>     x == 0.0001; // ??? huh
>
> That "overloads" is a container is an implementation detail. Or
> how about:
>
>      std::string a;
>      a = 'x';
>      a == 'x'; // oops can't compare char and string
>
> at any rate, It *is* possible to follow the semantics of Boost.Function:
> http://boost.org/doc/html/function/tutorial.html#id1187293
>

I've tried to understand why it seems strange to me the proposed
operator=() for assigning functions to overload:

void foo1();
int foo2(int);

overload f;
f = &foo1;
f = &foo2;

I came to the conclusion that all boils down to transitive property of
equality. In other words until childhood we are teached that

If a == b and b == c, then a == c

Because the following line

if (a = b)  // here = instead of == is intended
    assert(a==b);

should never fail for any properly defined operator=() and
operator==() it derives that operator=() as proposed for our overload
does not satisfy the above very intuitive concepts (because &foo1 !=
&foo2) so I would say it cannot be called 'idiomatic' for this case.

Marco