Hi Michael, On 10/13/07, Michael Fawcett <michael.fawcett@gmail.com> wrote:
On 10/12/07, Marco Costalba <mcostalba@gmail.com> wrote:
On 10/12/07, Marco Costalba <mcostalba@gmail.com> wrote:
So I would say a _possible_ policy is to not allow to register say
set(f6);
if is already registered a function with a "compatible" signature.
This is wrong.
I would have said:
" a _possible_ policy is that a call like
f.set(f6);
overwrites any exsisting function with the same signature *or with a compatible signature*"
Why is that better than your original wording? Your latter description breaks from precedence set by std::set and map.
I don't think we have to follow the precendent by std::set and std::map because of two very important reasons: 1.) The Boost.Overload implementaion does not follow the Contianer concept -- not by a long shot. If at best, it's closer to an std::pair<> than an std::map<> or std::set<>. This is because Boost.Overload is not a container -- it never was, and it never will be. 2.) The concepts and the use cases for Boost.Overload are not meant for run-time consumption: therefore throwing exceptions and runtime dispatch is out of the question. This means doing a set(&foo1) is better than saying insert(&foo1) because 'set' conveys better the concept which Boost.Overload is making as compared to 'insert'. See #1 as to why this is the case. Again, if you're looking for a container for runtime function objects, see Boost.Signals and the (other) library I'm working on, the Runtime Dynamic Dispatch Library. At best, you might want to consider an std::map<> of Boost.Function objects instead. I hope this makes things clearer. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]