Andreas Fabri wrote:
Hello, ... What is the overall strategy in the Boost project for accepting new topics for Boost ?
Hi, Andreas. I'll give one person's opinions in answer to your questions. I would say there is no set process, and no clear guidelines. The measures used most are about perceived need in the community, and ameanebility to a generic solution that is suitable for a broadly used library. The first is judged by the interest level of developers inside and outside Boost in the project. The second is judged partially by experience and partially by the library provided. That is, many of the Boost developers have done enough generic work to have some intuition for what problems are well suited to a generic solution, and this drives some of their work. However, if someone shows up with a good generic solution to a problem no one thought could be done that way before seeing the code, then the response is pleased acceptance of the solution. This is not enough for a Boost library, yet, but it is a good start. Coupled with clear design, solid cross platform coding, thorough testing and well developed documentation this start becomes what Boost wants from a library.
First, it seems strange to me that something as specialized as 45 degree polygons is considered to fit in, what I consider as the mission statement of Boost : ...
The review is not yet completed, so the decision may be that it does not fit in Boost. However you might be missing the forest for the trees. Many Boost developers (myself included) think a good geometry library would be a solid addition to Boost. It is an area that allows generic solutions, that has some very persnickety details that are very easy to get wrong, and that is applied in a large number of different problem and application domains. Given that starting place, the real question of the moment is whether Luke's library is the right geometry library for Boost. One feature of Luke's library is the inclusion of specialized implementations for the 45 and 90 degree polygons. It is a feature that may not be useful in many interested domains, but is very important in the domain for which the library was originally designed. If this was all the library could do, then it would not be a good candidate for Boost. However, many libraries include optimized routines for specific use domains along with the more generic foundation. I see nothing wrong with it.
When I say specialized, obviously something like boost::optional also solves a specific problem, but it is completely independent from a particular application domain. Boost.Polygon seems rather related to VLSI and PCBs, and the only criteria it fulfills is the license choice.
If, in the opinions of the reviewers and review manager the decision is that this library does not extend usefully outside the realm of VLSI and PCBs, then I would expect the result to be rejection. However, if it currently has broader applicability and the review process makes it clear how that can be built on to cover many of the needs in the field then those are points in the library's favor during the review.
Second, I am wondering about, when you add a first geometry related library without having the blue-print for "Geometric Computing in Boost", how can you hope that it will ever grow into a coherent whole?
best regards,
andreas fabri
Boost isn't a centrally controlled work from a pre-approved blue print project. Any blue print for geometric computing, or for any other extended topic in Boost is the responsibility of the developers who bring a proposal to the table. In the case of a geometry library in specific, one reasonable line for questions in the review is about how the choices in this library affect the options for adding other features that make sense as part of the core library, as well as building non-core features on top of the provided facilities. Once again, if the views of the reviewers and the manager are that Luke's library design cuts off important growth in the future then the library is unlikely to be accepted. However, providing concepts and abstractions that ease such expansions are a strong positive for the library. As stated before, this is one person's opinions and should not be taken as anything else. I still hope to review the library and so I may provide my own list of pros and cons for the design, implementation, and documentation. This is not that list. When I mention pros or cons above, they are by way of a thought experiment example, and nothing more. Take it for what it is worth, but I hope that helps. John