Cromwell Enage wrote:
One of the great bugbears I have with today's implementations of geometric primitives is the lack of a common interface between all of them. Take a point, for instance: should I access its coordinates using the public members x, y, and z? Or is that X, Y, and Z (capitalized)? Are they actually member functions instead of data? How about the subscript operator ([0], [1], and [2])? (Personally, I'd go with this one, since that is what the BGL and uBLAS algorithms are currently used to, and a point can be extended to have more than three dimensions if need be. But if you want interoperability with some of the other geometric libraries, you'll have to deal with their interfaces as well.)
access types and methods relate more to how the back-end of the library is doing what its doing. for example if there was a very strong matrix oriented approach, one would assume everything would be constructed from vectors etc. vectors or point structures, simplex forms they are all much of a muchness. there is a minimum amount of information required to describe something say a point in an unambious manner in a particular dimension, any method of definition you use will have to use at least that much maybe even more information. the real question is does it matter? one could always use a set of adapter to interact with objects in a way that feel is satisfactory. I believe whatever model is chosen, there will always be some group of people that will disagree with it for one reason or another.
Looking forward to seeing your work.
Its already in the boost vault under geometry and can also be accessed from http://www.wykobi.com Arash Partow ________________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net