On 10/10/07, Michael Fawcett <michael.fawcett@gmail.com> wrote:
On 10/9/07, Michael Marcin <mmarcin@method-solutions.com> wrote:
Dean Michael Berris wrote:
On 10/9/07, Marco <mrcekets@gmail.com> 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@gmail.com] [+63 928 7291459] [+1 408 4049523]