Luke wrote:
Yes, my own is very similar to what you show, except that I think n-dimensional point classes are pointless exercise, if you'll excuse the bad pun. What exactly is the benefit of making the order of the point data type generic? Are we saving typing in the library by merging the 2D and 3D point concepts? Do we pay a penalty for that?
By order you mean the number of coordinates right? This is actually really important to me. Coordinates in 2D and 3D are important, but 4D coordinates are too (eg, homogeneous or projective coordinate). Quaternians are 4D (well, 4 coordinates), and Plucker cordinates have 5 coordinates. Those are cases I came up with off the top of my head, but I know there are more examples I did not think of yet. There are very valid reasons that the size of a coordinate set should be specified at compile time for cases other than 2 or 3.
In your case you may not be paying a penalty because you are using compile time integer to index the point. You also provide compile time checking to make source the index is valid, I see, which is good.
In my case, I have the rich language of isotropy that performs runtime indexing. There are separate index types for 2 and 3d geometry and type safety prevents an invalid 3d index from being used with a 2d type. The language of isotropy provides a different kind of abstraction than what you are doing abstracting away the order of the point. The question that leaves us with is which abstraction is more valuable to the user, since they are mutually exclusive.
Huh? I think 'Isotropic' may need some clarification, I thought you meant just that distances in each coordinate's direction have the same unit of measurement. Your comments make me wonder if there is something more...?
Isotropy is quite valuable to the user, and we get very good results (in terms of code quality and productivity) using it. I doubt the user will parameterize the order of their own code,
I often try to ... if I correctly understand what "isotropy" and "order" mean here. -- John