-------------------------------------------------- From: "Matt Calabrese" <rivorus@gmail.com> Sent: Tuesday, February 24, 2009 3:43 PM To: <boost@lists.boost.org> Subject: Re: [boost] [geometry] area, length, centroid, behavior
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.
I think in this case it's not a matter of making the function more restrictive. The function to calculate area must be specialized for each type (or categorical concept) in some way. To create an area function that explicitly specializes the behavior for point or line types, one would have to create an additional function which does so explicitly. I.e. the developer has to add this functionality rather than curtail existing functions.
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.
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. Brandon