Re: [boost] GTL compile time vs. run time accessors

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-02 18:18:37

Fernando wrote:
>Acutally, that to_int() is getting back into runtime, so this wouldn't
>count 
>as a compile-time access even if it compiled.

Well, yes, I did say it wouldn't compile, so I figured I wouldn't follow
the rules.  Allowing the type to auto-cast to int breaks down the type
safety (since it allows unintended conversions.)  The point was to show
that type safety (not allowing conversion or orientation to and from
int) is incompatibile with the compiler requirement that the parameter
be a built in type.

>OTOH, this could be made to compile if desired:
>struct horizontal{ static const int value = 0 ; }
>template <class orient>
>coordinate get(const point& pt) { return pt[orient::value]; }
>coordinate value = get<horizontal>(my_point);

Since template metaprogramming is turing complete we can envision
implementing the entire set of runtime behaviors of the isotropic
objects in my library as compile time behaviors which would lead to a
truly dauntingly complex (potentially fun) exercise in template
meta-programming.  It might result in a functional library, but would
raise the bar for learning and using the library pretty much all the way
up to where only intellectual giants can reach it.

>then it should advocate higher level abstractions:
> vector delta  = condition ? vector(value,0) : vector(0,value) {}
> translate modify (delta);
> point = modify(point);
>which, being essentially coordinate-free, hides the coordinate-access
issue 
>from the user pushing into the library implementation.

I am guessing translate is a class, modify is an object of that class
that is constructed from a vector and provides a operator() which takes
a point, translates it and returns the translated point.  In fact, this
is quite close to the kinds of things we do.  If you grep for
predicated_value in my vault submission it is a standin for ? syntax,
and used quite heavily.  This is what we are, in fact, advocating people
do, and the isotropic types are often the condition (as you can well
imagine.)  The idea is to make the user code coordinate-free as much as
possible, allowing them to work at a higher level of abstraction and
pushing the low level details into the library (other than the heavy
algorithms, that is the service I'm providing with the library.)  I
don't agree that it won't matter to the user what accessors look like
inside the library.  I don't think I can completely abstract away the
existence of coordinates, nor do I want them to have to rely on their
own legacy interfaces.  Preferably, the user should feel empowered to
extend the library by writing in its style to suit their need.  From
that standpoint, the style shouldn't be allowed to become unnecessarily
complex.

Thanks,
Luke