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

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

Steven wrote:
>To the extent possible, the library should rely only on compile time 
>accessors, IMO.
>This does not preclude having the points also provide runtime accessors

>for users.
>It might work to allow either compile time access or runtime access and

>if either one
>is not given, fall back to implementing it in terms of the other.

The problem is that doing so makes the isotropic programming style I
alluded to in my reply to Bruno less workable.  The isotropic style is
pervasive in my library, and defines it, to a great extent.  This style
is a BKM for geometric programming that we have developed, and the
library is the means of propagating the BKM throughout the developer
community.  I can't be expected provide runtime parameters on all API
for the user's convenience then implement flow control in every case to
convert the runtime parameter into compile time constants and different
instantiations of template functions guarded by flow control.
Particularly since I frequently use the isotropic data type as the index
into an array, it seems silly to instantiate a different function for
every index value.  Moreover, I have defined a rich language of
isotropic types, conversions and behaviors which isn't compatible with
compile time parameters because the constant has to be a built in type
and not an object.  This breaks down the type safety of the parameter
and waters down the usefulness of the isotropic objects, since they
can't be used as template parameters.

The following does not compile (I wish it did):

const orientation_2d horizontal_constant;

template <orientation2d orient>
coordinate get(const point& pt) { return coord_[orient.to_int()]; }

coordinate value = get<horizontal_constant>(my_point);

because orient has to be a built in type.  If you throw away the
isotropic types: direction_1d, orientation_2d, direction_2d,
orientation_3d, direction_3d, winding_direction then you lose the type
safety and the rich language of behaviors provided by the library.  What
good are these types if they can't be used in the accessor?

We both have the same intent of improving programming practices through
library development.  The way people code geometry typically looks like:

if(condition)
        point.x() = value;
else
        point.y() = value;

You are advocating a style:

if(condition)
        point.get<0>() = value;
else
        point.get<1>() = value;

and I am advocating:

point.get(condition) = value;

I agree that compile time access is better than having two completely
different functions.  However, it leads the developer back to using flow
control instead of data to control the behavior of their code, increased
code bloat (in the user's code) and reduced code quality.  Isotropy is
somewhat unique to geometry because the exploitation of geometric
symmetry to refactor code doesn't really translate to all other domains.
In general, you are probably right that compile time accessors should be
preferred, but for geometry, isotropic style should be preferred.

We should think about what best accomplishes our goals rather than base
decisions on a meme.  I realize that my library is somewhat unique among
geometry libraries in that others don't use isotropy or do to a lesser
and less formalized extent.  That uniqueness is what makes the library
good.  Isotropy is a huge improvement in geometric programming over the
common practice.  That is why the interface requires the user to access
coordinates with the isotropic (runtime) type-safe parameter; it
encouraging the user to adopt the best practice.  That improvement is
what we are trying to get into the hands of geometry library users by
submitting the library to boost.  

Thanks,
Luke