Re: [boost] Geometry Template Library from Intel

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-04-30 18:44:19

Simonson, Lucanus J wrote:
> Now I have
> gotten approval to release the code to boost, licensed it under the
> boost license and uploaded it to the vault under Math Geometry.

Hi Luke,

That's good news.  I feared that you had been frightened-off by the 
previous discussions.

Although it's good to have the code, and no doubt some people who can 
scan C++ faster than I can will really appreciate it, what I'd love to 
see is more in the way of rationale and concept-documentation.  For example:

- My recollection of the last part of the discussions the first time 
around was that they focused on the "nasty" way in which you made it 
possible to adapt a legacy struct to work with your library, and in 
particular how you added methods to the class by casting from a base 
class to a subclass.  It would be great to see a write up of the 
rationale for that compared with the alternatives.  Perhaps this could 
just be distilled out of the previous discussions.  My feeling is that 
it may come down to this: what you've done is the most pragmatic 
solution for your environment, but it isn't something that could ever 
make it into the C++ standard library (since it used casts in a 
non-standards-compliant way).  So, should Boost only accept libraries 
that could be acceptable for C++, or could Boost have a more liberal 
policy?  Also, how much weight should be put on the "legacy" benefits 
of your approach?  My feeling is that the standard library, and Boost, 
typically prefer to "do it right as if you could start all over again", 
rather than fitting in with legacy problems.

- Your library has a limited scope: 2D orthogonal and 45-degree lines.  
(And its name ought to include some indication of that.)  I would like 
to see some exploration of in what way your interface (as opposed to 
your algorithms) is tied to this domain, i.e. to what extent your 
interface could be re-used for a more general or differently-focused 
library.  For example, could you have a Point concept that could be 
common with Barend's library, allowing Federico's spatial indexes to be 
used with both?  Or would do you require (e.g. for algorithmic 
efficiency reasons) a point concept that is inherently incompatible?

- There are plenty of application domains for computational geometry.  
Presumably you're processing chip layouts.  The other case that I can 
think of for orthogonal geometry is in GUIs (until you have windows 
with rounded corners).  Everything else that I can think of (GIS, 
games, mechanical CAD) needs arbitrary angles or 3D.  You may be 
proposing something that no-one else here has any use for, except as a 
stating point for more geometry libraries in Boost - in which case your 
concepts and other interface choices will be given a lot more attention 
than your algorithms.

Regards, Phil.