Bruno wrote:
I understand what the original poster was trying to convey, and
your
opinion is valid,
but they both need much more clarification than saying things should be interchangeable.
Indeed, things have to be clear on that point, and I'm a bit confused about what really constitutes the concept of a point. What I have understood until now is that a class is the point if it exposes: * the value<>() getter and setter * coordinate_type * coordinate_count
and that besides this, the .x and .y of the point_xy class were just some syntactic helpers provided for an easier external use of this class. But I see that almost all the algorithms use .x and .y, which means that they won't work with the basic concept I just described. Shouldn't all those algorithms be implemented in terms of value<>() accesses ?
Some headers that use .x and .y: area.hpp strategies_point_xy.hpp centroid.hpp correct.hpp envelope.hpp intersection_linestring.hpp intersection_segment.hpp
Bruno [John Femiani]
This is why I would like to see concepts spelled out like this: http://www.boost.org/libs/concept_check/reference.htm#basic-concepts as is done by other boost libraries which I like, such as gil http://stlab.adobe.com/gil/html/index.html, BGL http://www.boost.org/libs/graph/doc/graph_concepts.html , fusion, and others. They all clearly specify their concepts using the SGI style and provide concept checking classes. To me that makes them easy to understand. IMHO the core need from a point library is the concepts, not the models, because there are so many different well-tuned geometry libraries that exist, and the idea is that boost _algorithms_ work on any "point", rather than that boost have a great point class (those are easy). Also, I already disagree about the idea that a point should have coordinates. CoordinatesConcept should be part of a separate concept. Of course a useful point class will model both the coordinates and the point concept. To me a point should really support transform, scale, rotate, shear, and distance operations as free functions (maybe more). I don't know how to handle the idea of a 'space' or a 'kernel'. BTW, I came across lib2geom the other day and they seem to be using concepts: http://lib2geom.svn.sourceforge.net/viewvc/lib2geom/lib2geom/trunk/src/c oncepts.h?view=markup