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

Subject: Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009
From: Andreas Fabri (andreas.fabri_at_[hidden])
Date: 2009-09-02 02:31:56

John Phillips wrote:
> 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. 

Hello,

Given that you say "a good geometry library would be a solid addition to Boost"
the real question (instead of the real question of the moment) is, if it makes
sense to call "Luke's library" "the right geometry library".

It's as if someone came up with a new sin function API, and stated
that this is now "THE Boost Scientif Library"  (I refer to the GSL here).

The point I want to make is that what Luke did is certainly a nicely
crafted, robust code, his explanation on how he kept 45 degree polygons closed
under Boolean operations shows that he knows what he does, the original code
is in production mode for years, so the overall quality is certainly high,
but it only deals with a special case of Boolean operations,
and would, with this respect, be a special case in a single chapter of
a real geometry library as CGAL, namely
http://www.cgal.org/Manual/3.5/doc_html/cgal_manual/packages.html#Pkg:BooleanSetOperations2

Again, I write this not in order to say contribute to CGAL or to gpc, or
to whatsoever library, but that if you or Boost thinks
"a good geometry library would be a solid addition to Boost"
then Boost should first think about the design of the foundations of the building
before adding an architectural detail to it like a bay
http://commons.wikimedia.org/wiki/Category:Bays_%28architecture%29

best regards,

andreas

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
> 
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
>