On 07/01/10 20:30, Larry Evans wrote:
On 07/01/10 17:48, Raffi Enficiaud wrote: [snip]
The fact is that the Functor itself is not always directly callable with the Args, and there is two sequences of Args that should be considered: the one for the interface and the other for the arguments of the template function. So the level of indirection induced by the convertors mentioned earlier should be considered. For instance a base class pointer to a derived class reference (again... :) ). All these logics are embedded in the convertors, defined for each pair of types (interface, concrete), which make it very easy to extend to new types.
Ah! This is was I was missing. IOW, dispatch_object must know the signature ( argument types) of 2 functions, the interface function and the template function and attempt conversions between corresponding argument types. In contrast, reify_apply simply converts each "abstract" argument to it's actual "concrete" value before 1st checking that the concrete values are consistent (using apply_ftor_check_args) with the Functor. IOW, there's just one function (or Functor) in reify_apply's case, and that's not examined until all conversions are done because only a runtime value of the abstract objects(the tag value in case of the reifier_switch and the virtual function table in the case of reifier_visitor) are used to convert to the concrete objects; whereas, with dispatch_object, 2 functions are used and the signatures of both are used to guide the conversion.
[snip] This sounds something like functor in category theory: http://en.wikipedia.org/wiki/Functor What you have is 2 functions: f_i the interface function f_t the template function and you want someway to convert a call to the f_i to f_t. So, given: t_i0 f_i(t_i1, t_i2, ..., t_in) and: t_t0 f_t(t_t1, t_t2, ..., t_tn) you want a set of conversion functions: t_tj c_j(t_ij) so that you can call: t_t0 f_t(c_1(t_i1), c_2(t_i2), ... c_n(t_in) ) or something like that, right? -regards, Larry