Re: [boost] [challenge: Dynamic Overloads]

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-10-12 06:51:36

Marco wrote:
> On Wed, 10 Oct 2007 08:24:08 +0200, Johan Nilsson
> <r.johan.nilsson_at_[hidden]> wrote:
>
>> Michael Fawcett wrote:
>>> On 10/9/07, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
>>>>
>>>> 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'.
> [snip]
>>
>> I'll persist (yes, yes ... the imfamous bicycle shed): What's wrong
>> with add:
>>
>> functions.add(&foo);
>> functions.add(&foo); // Throws
>> functions.insert(&foo); // Returns false
>> functions.replace(&foo); // Overwrites if exists, inserts if not
>>
>> The above is based on the fact that only one overload of each
>> signature is
>> stored - analogous to method overloads.
>>
>> If some kind of multiple dispatch is desired - how about
>> "multi_overloads"
>> (compare set/multiset, map/multimap).
>>
>> / Johan
>>
>
> Well, my point of view is that you shouldn't see the proposed
> implementation
> as a container but just as an extension of Boost.Function.
> It would be overkilling if Boost.Function had method like "insert" and
> "replace"
> instead of a simple operator= , and, IMO, the same it's true for the
> proposed
> overload implementation.

Sorry. I still believe that this violates the LSP. IMHO "overloads" should 
be designed for standalone usage, with method naming (and perhaps operator 
overloading) that reflect their true nature.

If you want to be able to use "overloads" just as an extension of 
Boost.Function, supply the users with e.g. an "overloads_function_adapter" 
wrapper.

Nevertheless, I rest my case. My opinion seems to be in minority here.

/ Johan