Hi, Here are the few answers I can give right now, I let Barend complete or correct me, and answer the questions for which he has a better view of the library than me.
- The names of the geometric objects isn't dimension agnostic, which might or might not be a problem. A circle is a circles in 2D, but a sphere in 3D. A line, however, is always a line. Same for segment and polygon (and all yet-to-be-implemented objects which are polygons). I think naming should try to differentiate objects that stay what they are when dimension varies or that evolve with that dimension. Either way, the name convention should be clearly explained in the documentation.
Indeed it's something that should be done, we had a quick discussion about that with Barend and decided to postpone that for now. This kind of subject is never easy. For example, I'd like to rename circle into hypersphere or nsphere, but then we'll also have to clarify the meaning of some algorithms. For example what we currently call the area of a circle is actually the volume of an hypershere<2>...
- Also, while most names are 2D-centric, "box" is 3D-centric. This seems fairly inconsistent. Or maybe it's just me and box is actually dimension agnostic.
box doesn't sound less dimension agnostic than anything else to me, but this can be discussed...
- Still about "box", it is really an axis-aligned (whatever that means in non-cartesian geometries) hyperrectangle. Since "box" can not contain an arbitrary box, maybe it should be called minmaxbox or aabox or whatever.
aabox could be good.
- envelope calculates the minimum bounding axis-aligned hyperrectangle for an object. It might also be desirable to have a way to calculate the minimum bounding hyperrectangle (non necessary axis-aligned) or the minimum bounding sphere. What names would those algorithms have if envelope is reserved for AABHR?
Indeed, maybe this name could become minimum_aabox and be accompanied by other algorithms like minimum_box, minimum_sphere (minimum_hypersphere??), etc...
- Modeling sequences of polygons as iterator pairs seems an annoyance to me, ranges are much prettier to handle since one variable is thus sufficient to represent one object (while two are required for iterators).
Maybe we can double each algorithm to have the choice between passing a pair and a range. AFAIK, this will be the approach of the algorithms in C++0x, am I right?
- Algorithms should be overloaded to handle all geometric objects. I assume the reason it wasn't done is simply because of time to do so.
Yes I suppose that we'll be able to add those overloads once the general design will be validated. About the default constructors debate: like Mathias I'd be inclined to have constructors that guarantee the integrity of any existing object and make checks useless, that's the choice I make in most cases. Luke, could you give some actual examples of cases where you found really annoying your legacy polygon class? Bruno