Dear Larry, Larry Evans <cppljevans <at> suddenlink.net> writes:
On 07/02/10 07:20, Raffi Enficiaud wrote:
Larry Evans <cppljevans <at> suddenlink.net> writes: [snip]
This sounds something like functor in category theory:
[snip]
Ok now I understand what you meant. Indeed the purpose of the dispatcher is to find the appropriate functor depending on the input types (if we discard the return type). Suppose I have an "interface" function (mapping) f: X -> Y. X and Y \in C \times D are the elements on the interface level. Several implementations {t1, ...tn} exist at the template level for doing the job of f, then the dispatcher "d" should find the appropriate functor, in order to call the appropriate implementation. d: f \times X \times Y -> F st. F \in {t1, ... tn} \cup \emptyset F(f) : F(X) -> F(Y) So the dispatcher returns a functor F (or fails is no implementation is available), and do the call. In my case, I have for instance a image interface which is polymorphic on the pixel type and dimension of the spanned space. "f" at the interface level would be a "copy" from one image into another, the {t1... tn} are the real implementations (with for instance memcpy when appropriate). What deviates from this viewpoint is that the spaces of X and Y are not necessarily "categories" (no identity element, no special operations, etc.). Unless we define the indentity element as being the "function does nothing", X and Y are become functions and set of functions respectiveley ("copy at interface level" and the implementations of "copy at template level"). f is then mapping between the interface function and the set of template functions. F becomes the mapping (call) through the dispatcher: F(f): F(X) -> F(Y) F(X): function at the interface level F(Y): selected implementation (or void) However, in this view F(Y) does not depend on X. In my point of view of the dispatcher, the selection is made rather on the right side of the arrow, since F(X) can be any implementation. Maybe it is more suitable to say: F(X): selected implementation depending on the real types of X F(Y): call to the selected implementation (?) Again, F(X) does not depend on Y... So I don't know exactly how the dispatching can better fit into the functor representation. I am more at ease with an "embedding" representation. The dispatcher tries to embed (express) the interface types (X) in a "specific" (template space) type (Y), for all the parameters. We are not interested in any possible mappings in the space of X or Y, but only in the points (elements) in both sides. I don't know if I was clear enough. What do you think? Do you think it might be relevant for boost?
-regards, Larry
Regards, Raffi