Re: [boost] Geometry Template Library from Intel

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

Fernando wrote:
>struct point_concept
>{
>   template<class T>
>   typename point_traits<T>::coordinate_type
>   static inline get( T const& point, orientation_2d orient )
>  { return point.get(orient); }
>} ;
>
>which users can specialize for concrete types just as in your case.
>The difference becomes apparent in the user side syntax:
>  point_concept::get(point1, HORIZONTAL)
>instead of:
>  point_traits<T>::get(point1, HORIZONTAL)

I like that!  Believe me, you don't have to explain why that is better,
I was a little worried about the verbose syntax I was generating in my
example code.  This is much cleaner.  Thank you.  

>Now of course I would have free functions instead:
>   template<class T>
>   typename point_traits<T>::coordinate_type
>   static inline get_component( T const& point, orientation_2d orient )
>  { return point.get(orient); }

In the previous example the struct was merely a standin for namespace,
with the advantage that it can be passed as a template paramemter (which
has all the advantages that I can appreciate), but haven't you given up
both the advantage of disambiguating the function name and being able to
pass the concept it belongs to as a parameter by making the accessor a
free function?

>Now say that you want to add vectors to the library, and vectors have
x,y 
>components as well: what do you do *now*?
>You could create yet another accessor with essentially the same method
>  vector_concept::get(vector1, HORIZONTAL)
>
>but then users would have to specialize both point_concept and 
>vector_concept even if their concrete class is the same for both.

In that particular case I would allow a geometric vector to model a
point concept and reuse that concept and have the vector concept include
only the new behaviors that are specific to a vector: get magnitude, get
direction.  My layered rectangle reuses the rectangle concept and adds
layer only in its own concept.  If you mean you want to get the axis
parallel components of a vector you would probably want new functions
for that, not reuse the syntax of a point's accessors, which would more
aptly give the vector's position.  However, I do see you point about
refactorability.  I'm not sure I buy it; perhaps a more apt example
would help.  I don't really mind typing partial duplication of
interfaces for similar concepts since the goal of doing so is to make
the API intuitive for the user.   

Thanks again,
Luke