Re: [boost] Any interest in dynamic dispatching mechanism from "interface" to template functions ?

Subject: Re: [boost] Any interest in dynamic dispatching mechanism from "interface" to template functions ?
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2010-09-16 11:56:27

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:
> >>
> >>    http://en.wikipedia.org/wiki/Functor
> >>
> [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