Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009

Subject: Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-08-29 14:08:55

Before doing an actual review, there are a few things I would have to 
discuss.

The library appears to be quite adequate at performing operations on 
dynamically-sized polygons of integral coordinates.

I wonder how difficult it would be to extend the system so that it could 
work with statically-sized polygons. (the library only provides 
rectangles, basically polygons 90 which a static size of 4)
I'm thinking of triangles in particular.
Also, could algorithms like triangulation eventually become part of the 
library?

Still in the static vs dynamic argument, it appears points implement by 
default the static coordinate lookup (the x() and y() functions) in 
terms of the dynamic one (the get(orientation_2d) function).
Shouldn't it be the other way around?

The documentation says euclidean_distance was named so instead of 
distance to avoid ambiguity with std::distance.
Isn't that problem simply solved by qualifying the call? Or maybe I'm 
missing something?

Personally, I tend to prefer functions that return results rather than 
those that take some input and modify it, since the latter require the 
objects to model the mutable variant of the concept, and mutation makes 
code more complex to reason about by undermining referential 
transparency and equational reasoning. (part of that sentence was 
copy/pasted ;)).
Couldn't a function like "center", for example, instead of taking a 
point to modify, directly return some kind of simplistic expression 
template, then perform the evaluation when a conversion to T is 
requested, using T as an output type?

Finally, about the operator overloading for set operations, I would like 
to be able to avoid pushing the namespace in the global one if possible.
I think it would be nice to have a "ref" function or something that 
would make objects just behave like a reference to the original object 
but within the right namespace so that the operators get picked up by ADL.
Functions that would return expression templates like discussed above 
could also make their return type in the right namespace so that it gets 
picked up by ADL too.