On Tue, Feb 24, 2009 at 12:33 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
0, indeed.
Rename length to perimeter, since that is more generic. For all geometries, which are only sets of points, the centroid should be
the average point. Undefined behaviour. An invalid polygon shouldn't be allowed in the first place. Ideally, that should be prevented by the type system.
Agreed with all of these. As I see it, with any reasonable generic definition of the functions mentioned, their behavior seems to fall into place just as Mathias specified for points, lines, etc. I understand that some people may be worried that you might accidentally pass points to an area function when you didn't mean to, but in my opinion, that's not very likely and it is not worth putting an unnecessary requirement on a function simply because in some cases people might use it incorrectly. On Tue, Feb 24, 2009 at 2:13 PM, Brandon Kohn <blkohn@hotmail.com> wrote:
I agree that you can interpret these things as you have stated. The part that I find hard to accept is that I should somewhere in the code want:
point a; line b; .... //! Assuming the "dimensionally agnostic" function for the 'area' metric is called content. double aArea = content( a ); double bArea = content( b );
My intuition tells me that such a call is far more likely to be a logic-error than the case that I really want to know the area of a point or line. So if I were defining the interface I would make the choice that I have advocated. Of course the world won't end if zero area is returned for points, lines (or type void for that matter.)
I question both how common such a logical error would be and why the library should be responsible for trying to prevent it. While I would agree that all attempts should be made to make the library (or rather any library) intuitive and difficult to misuse, I don't believe preventing a hypothetical mistake by making a function have more strict requirements than necessary is a good design decision. If in practice a lot of people were accidentally passing points to the area function, then maybe this would be more of a concern, but I really don't see that as being a problem here. I'd rather have the function work in the way that makes sense. -- -Matt Calabrese