
Boost : 
Subject: Re: [boost] Any interest in dynamic dispatching mechanism from "interface" to template functions ?
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 20100916 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk