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.