Re: [boost] [GTL] redesign checked into sandbox

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-11 00:51:11

John wrote:
>I want the flexibility to allow 'at' to return a reference. The
>references would then be to the underlying types internal members,
which
>could be of any type.

Why?  For a small type like a single coordinate value return by value
will be efficient?  Do you want the convenience of being able to use it
to get a modifiable reference?  What if the data type doesn't have an
explicit data member, but computes it on demand and updates values it is
computed from when it is modified through the accessor?  

>I have applications in mind where coordinates may be references to
>unsigned chars, so the type of the reference can not be the same type
>used for, say, an inner product.  
>
>I required only a 'scalar' type because I figure that is the minimal
>need. Coordinate elements, regardless of there raw types, need to be
>mixed, added, divided, etc. 
>
>Presumably things like euclidean norms are callable objects and
>something like result_of<euclidean_norm(Coord)>::type can be used to
get
>or control its result.

You want such functions to be functor objects?  Why not just let it be a
function and create a functor from it when(if) you need one?

>In my concept a coordinate_accessor is a UnaryFunction object an I
>should make sure ::boost::result_of works, huh..?
>

I guess it all depends on how far we want to go and how complicated we
are willing to let it get.  I'm driving at simplicity, elegance and
minimal dependencies.  I want user code to be as dead simple and
straightforward to write as possible.  I like the current idea of
providing a library of free functions that infer types from their
arguments using metafunctions and call the appropriate algorithm
associated with the concept.  Making functions into functors leads to a
lot of extra boilerplate in both the library and the user code.  I'd
need to hear a good rationale for that.

>Also maybe there needs to be Metric or Norm concepts to, eh?

I guess that depends on whether they are functions or objects.  We would
only want concepts for template parameters that may be supplied with
user types.  To that end, we need to be intentional about what is useful
to be made generic rather than just making everything generic because we
can.

For me the concepts in the library serve two purposes.
1. They allow user types to interface with my heavy algorithms, easing
and improving the quality of integration of those capabilities into an
application.
2. They provide the user with a set of useful behaviors for geometry
objects that are superior to what they are likely to have on their own
types.  By superior I mean completeness, consistency and ease of use.

The only things that need to be made concepts, in my view, are geometry
data types, not algorithms or behaviors.

Thanks,
Luke