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

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-05-11 02:28:47

Luke wrotE:
> 
> 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 was thinking along the lines of std::vector::at, or Fusion. Certainly
I was not worrying about performance, I just dont want to impose
unnecessary constraints, and I want to stick close to the semantics of
Fusion or MPL sequences. 

In the case of a computed coordinate, then the raw type would not be an
lvalue and the coordinate would be immutable. Thats fine, but we will
also need to modify some points. If you want to use proxies, then I
think the way to make sure proxies are allowed is to use a proxy as a
coordinate type in the archetype. 

Anyhow I am not dead set on that point -- it just seems like the concept
should impose minimimum constraints on the coordinates type, and
allowing heterogeneous coordinates seams less restrictive.

> >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?
> 

Functions are callable... and result_of should work on a function unless
it is overloaded I think (I have to check).  What I am saying is that I
think I would prefer result_of instead of a new metafunction for every
operation.

> >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.
> 

http://www.boost.org/doc/libs/1_35_0/libs/utility/utility.htm

"The implementation permits the type F to be a function pointer,
 function reference, member function pointer, or class type. "

I have been using result_of and I love its simplicity. IMO
dependancies on libraries that will become part of the standard 
is tolerable.

We could also follow the fusion example again and have a 
result_of namespace, and in there have metafunctions named
after the corresponding regular functions.

> >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.
> 

Developers are users too! Hopefully this library will inspire 
a lot of new extensions & contributions over time, right?

Plus there may be some benefit to passing a metric around. For 
instance, we might want to have a way to find out if it is 
... isotropic ....?

Anyhow I think the thing to do is focus just on coordinates at 
the moment, and I think that whatever we do should stay very
close to the Fusion approach.

-- John