
I agree that this is certainly similar to what I have and that it is very good. There is however a distinction in that the access traits in my design are separate from the general point traits. I think that this is an important distinction. When you strip a basic point in N dimensions from >any nomenclature, you essentially have a data structure that can be describing >a location in any coordinate frame of dimension N. It is only through choosing a coordinate frame that the dimensions of the point takes on meaning (well, strictly speaking this isn't true... I have a text that speaks quite highly of coordinate free geometry..). This is why I have created access
Brandon wrote: traits
which are aligned with a particular coordinate frame. It gives me the means to have a legacy point type (which uses a particular framework, polar coordinates) which can then automatically work in an algorithm which requires Cartesian coordinates. By specializing an access traits type for the legacy point, I can make all required transformations from r, theta to x,y without doing any explicit translations to the underlying point type. The result is that I can put my polar points in and still use all these
great algorithms which require Cartesian coordinates. Also any outputs or modifications to inputs are automatically written back in polar coordinates due to the same interface (via the construct method of the access traits.)
My point traits above are implicitly for 2D Cartesian points. You could specialize it to access a 2D polar coordinate point data type and it would work similar to what you describe. I don't provide direct access to the underlying x and y values, so they can be converted to and from whatever the point does store in the accessor functions. I don't have an N dimensional point concept in my library because I didn't see a need for such. If I did, I might very well have come up with a design similar to yours or what Barend is going to show us soon. I'm not opposed to n-dimensional points, I just don't have any use for them, personally. Luke