Re: [boost] [geometry] area, length, centroid, behavior

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2009-02-24 15:43:59

On Tue, Feb 24, 2009 at 12:33 PM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> 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_at_[hidden]> 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