Re: [boost] [challenge: Dynamic Overloads]

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-10-09 13:03:27

On 10/10/07, Michael Fawcett <michael.fawcett_at_[hidden]> wrote:
> On 10/9/07, Michael Marcin <mmarcin_at_[hidden]> wrote:
> > Dean Michael Berris wrote:
> > >
> > > On 10/9/07, Marco <mrcekets_at_[hidden]> wrote:
> > >>
> > >> About method name, at present I keep my generic "set" at least is
> > >> simmetric with "get" :-)
> > >> Obviously I'm open to discussions, but don't make it the main issue of the
> > >> project :-)
> > >>
> > >
> > > I agree. 'set' seems alright to me too. It's add and insert that I
> > > have problems with. :)
> > >
> >
> >
> > How about "enable" inspired by controlling overload resolution with
> > enable_if.
>
> At the risk of bring down Joel's wrath, I'll add another suggestion to the hat.
>

I'm risking Joel's wrath as well here by obliging the discussion, but
then I'll go ahead and share my thoughts nonetheless. :)

> What about 'include'?  As in, "include this in the overload resolution set."
>

I thought about this, and the only problem is that it assumes that
'include' does not replace the already existing mapping between a
function signature and the actual function being 'included'. Consider:

void foo(int) { };
void bar(int) { };

overloads<void(int), void(std::string)> functions;

functions.include(&foo);
functions.include(&bar);
functions(1); // will imply that 'foo' and 'bar' will both be called

The above code suggests that functions(1) should call both foo and
bar, because both functions are included in the overload set. If this
is the behavior you're looking for, I think Boost.Signals does tihs
perfectly well -- only Boost.Signals is also monomorphic, meaning it
contains (like Boost.Function) only function wrappers that share a
single signature.

Thinking about it more, maybe Boost.Signals might also benefit from
something like Boost.Overloads because if for example slots (or
handlers) can be connected to signals and dispatched depending on the
signature of the signal invoked, then we have a clean way of providing
a coherent interface that's statically dispatched *and* idiomatically
sound.

The drawback is I think this might change the way Boost.Signals is
implemented -- currently there's an external library built, which I'm
not sure will be affected with the use of Boost.Overloads. Besides,
applying it to the concept of Signals might be pushing it -- but I may
be wrong.

Nonetheless, I'm thinking at this time 'set' is fine, especially when
it supports both argument type deduction *and* the explicit index
specification.

Interesting idea though, thanks for sharing your thoughts. :)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mikhailberis_at_[hidden]]
[[phone]]
[[phone]]