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

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-02-24 17:32:16

> From: "Matt Calabrese" <rivorus_at_[hidden]>
>> 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.
 
Brandon Kohn wrote:
> I suppose this is just where I differ from everyone. A point is a
> 0-simplex. It has no units (dimensionless) in content space. A line
> segment is a 1-simplex. It has units of length in content space. The
> 2-simplex (triangle) has units of area. A 3-simplex has units of
> volume and so forth with increasing dimension. It doesn't make sense
> IMO to query the area of a point any more than it does to query the
> length or volume of a point. I cannot see a viable use-case for
> wanting it, and based on that I don't see why the developer would
> want to add additional code to support it. 
 
I'm going to back Brandon up on this one.  There is no valid usecase for asking for the area of a point.  It should be a syntax error.  I also agree that writing such a function is a waste of time even if it were not also harmful to the integrity of the API by breaking down conceptual type safety.  I also think it is a bad idea to provide a catchall default area() function that returns zero for every concept that doesn't have an override area() function.  This changes all compile time errors related to type misidentification at compile time into runtime errors, the worst possible thing the library author could do.  This makes the job of library author much harder because it turns his own mistakes into runtime errors rather than compile time errors.

Case1:

Polygon p1;
//lots of code
if(some condition) {
        Point p1;
        //some more code
        result = something + area(p1); //oops, which p1 did they mean?  Is it really so unlikely?
}

Case2:

Polygon p1; //this polygon doesn't properly model polygon concept
Result = something + area(p1); //default version of area assumes object type must not have an area and returns 0!

All user error looks unlikely in isolation.  In fact, programmer error only happens at a rate of about 1%.  For every 100 lines of code the library user writes we want them to get an extra syntax error instead of an extra runtime error because the runtime error costs 10 to 100X more to fix.

Luke