On Sat, May 17, 2008 at 1:39 AM, Marco Costalba <mcostalba@gmail.com> wrote:
On Fri, May 16, 2008 at 9:03 PM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
It's still a vector of signatures. There are two kinds of signature here (by convention or protocol):
* int(int, int) is the usual C/C++ call signature * plus(_1,_1) is our new emerging polymorphic signature by convention
Ok, now I understand, thanks, but still there is a fundamental difference between int(int, int) and plus(_1,_1), namely the first it's just an interface but the latter does real work, actually adds stuff.
I try to explain myself better with an example starting from the normal functions case:
<snip>
So here we have:
msf::function<mpl::vector<_1(_1, _1), bool(_1)> >
not
msf::function<mpl::vector<plus(_1, _1), is_positive(_1)> >
because the vector of function signatures define the interface that function should have to be wrapped by the overload set, as you prefer to call it ;-), so also in polymorphic case the vector should keep "polymorphic signatures" that different polymorphic classes with the proper polymorphic signature should match to be _wrapped_ by the overload set, not to be the underlying function, replacing boost::function as you suggested.
In this case boost::function should be replaced by a wrapper of polymorphic functors, not by _a_ polymorphic functor defined in mpl::vector at msf::function instantiation.
Am I missing something?
BTW I don't even figure up how this wrapper of poly objects looks like ! or if it even exist.
This is interesting, but something different. _1(_1,_1) and bool(_1) are not what I meant by polymorphic signature. I haven't thought about how you would do this either or if it's even possible. The definition for a polymorphic signature protocol that I have in mind requires that the first position be a callable object or referenced wrapped callable object. _1 and bool are not callable objects - no operator(). So, for the first position, a polymorphic signature is almost exactly like the signatures passed to result_of. (BTW, this could be enforced by the compiler with a concept check.) For all the following positions in the signature inside parens, they can be either an actual argument type or a placeholder. Placeholders indicate a template parameter in the function's argument list (not an unspecified function object outside the argument list). Actually, come to think of it, _1(_1, _1) would probably not be possible because it doesn't encode the type of a polymorphic function object, so there's no way for the compiler to use that type's set of overloaded operator()s later on at the call site. _1(_1,_1) is type erasure again and that breaks polymorphic function objects.
I'm sure there's more to it, but that gives you an idea. Of course, the first thing you need is an nary version of polymorphic_function. If you're serious about this and that's the direction you'd like to go in, I'd be glad to start working on it tomorrow!
Great!! I'm very interested in polymorphic generalization too, but I would think is difficult stuff, too difficult for me alone ;-)
Well, I ended up taking the weekend off. ;-) But I'll download your latest version and get back with you later this week. This will be fun if nothing else! Daniel Walker