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: int add(int a, int b) { return a + b; } int sub(int a, int b) { return a - b; } bool is_positive(int a) { return a > 0; } bool is_negative(int a) { return a < 0; } msf::function<mpl::vector<int(int, int), bool(int)> > f(add, is_positive); assert( f(3, 2) == 5); assert( f(6) == true ); f = sub; f = is_negative; assert ( f(3, 2) == 1 ); assert( f(6) == false ); Ok. Simple. Now extend to polymorphic case: struct add { template<class T> T operator()(T a, T b) { return a + b; } }; struct minus { template<class T> T operator()(T a, T b) { return a - b; } }; struct is_positive { template<class T> bool operator()(T a) { return a > 0; } }; struct is_negative { template<class T> bool operator()(T a) { return a < 0; } }; Now what I would expect for this generalization is: msf::function<mpl::vector<_1(_1, _1), bool(_1)> > f(plus, is_positive); assert( f(3, 2) == 5); assert( f(3.5, 2.5) == 6.0); assert( f(6) == true ); assert( f(6.7) == true ); f = minus; f = is_negative; assert ( f(3, 2) == 1 ); assert ( f(3.5, 2.5) == 1 ); assert( f(6) == false ); assert( f(6.7) == false ); 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 _really_ totally different also from an implementation point of view. Indeed a MSF boils down to a hierarchy of operator=() each one defined on a given signature and each one forwarding to a corresponding boost::function
I started looking more closely at your implementation, and I like the way you do the class hierarchy. But the important part here is the hierarchy of operator()s right?
Yes. I meant that. It was a silly typo, I meant " a hierarchy of operator()"
This won't compile yet, but the change I'm think of (starting from the msf_27_4_2008.zip version) would be something like
This is very old, now is out msf-1.1.zip and in few hours it will be out msf-1.2.zip with the improved interface for poly objects, namely the remove of set_polymorphic_object() and use of operator=() instead. I suggest to download one of the above because they are very different from the version you have.
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 ;-) Marco