Marco wrote:
On Wed, 10 Oct 2007 08:24:08 +0200, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
Michael Fawcett wrote:
On 10/9/07, Dean Michael Berris <mikhailberis@gmail.com> 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