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.
That's good news. I feared that you had been frightened-off by the
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk