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