On Wed, May 14, 2008 at 5:05 PM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
Your multi-signature function is not merely an extension of boost::function; it is a container of callable objects. Why not make it act like one?! ;-)
Daniel, I have to say that I agree with you 100% on the design goals you present. In particular I'm a huge fan of keep it simple and do one thing and do it well. Also the argument of let MSF be orthogonal to standard algorithms is very sound. What I'm asking myself is that if, in its current form, MSF can be taught as a container. As example you wrote this overload_set<mpl::vector<int(int), float(float)> > functions; fill(begin(functions), end(functions), ref(my_polymorphic_functor)) But begin(), end() and fill() need a forward iterator concept to work. In it's current form, if I have to do the analogy with a container I would say that MSF is more similar to an hash then, say, a vector or a list. It's a kind of hash with the key being a function signature: you throw in a signature and get the underlying object. There is no concept of order or position of an overload against another at least "in its current form". I would need to throw in a good chunk of metaprogramming infrastructure to get compile time constants for indices and a bunch of metastuff to handle them. At the end probably it would be another thing. Also in the two examples that I wrote in documentation (a dynamic dispatcher and an object factory) MSF is used as a value, as a container item, of a std::map in the first case and of a tuple in the second case. Also the examples of Govanni, for what I have understood, treat MSF more has a value or a function object then a container. Of course you are 100% right when you say that MSF could be a container, but IMHO it depends a lot on the use. I explain myself better. When dealing with MSF I tend to recognize two phases or two steps (I'm not native speaker so please forgive me if I do not choose the correct words). First step is to load the gun: Define a MSF object and assign to it the functions/functors Second step is to shot: Use one or many of these MSF object to make the job done (call stuff, dynamic dispatch, handle containers of MSF items and so on) I would say that I see more MSF as a container in the first step, and as an item (of another container) in the second step. Anyway this is very hand waving and probably fundamentally silly. So, just to be concrete, I've pushed to boost Vault the file msf-1.1.zip with the new stuff that arise from these very good discussions. In particular there is the result_of support and the "controversial" ;-) set_polymorphic_object() code. I have updated tutorial.html and test.cpp to reflect this. One word regarding the API: it is EXPERIMENTAL. Reading this thread I found a lot of good arguments to change the current function names, unfortunately not all suggestion went in a single direction. So I more or less left the API as it was, but I understand a lot of names, starting from "multi-signature function" itself, are simple placeholders for the future better ones as soon as we agree on what they are :-) Thanks for your precious feedback and help, response of all of you has been overhelming, above my best expectations. Thanks Marco