Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009

Subject: Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009
From: John Phillips (phillips_at_[hidden])
Date: 2009-09-01 23:54:23

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