[Boost-announce] [Boost Review] Property Tree Library accepted
I have the great pleasure to announce that Marcin Kalicinski's
Property Tree Library have been accepted into Boost
The votes were as follows:
- yes: 11
- no: 3
Congratulations to Marcin!
I would like to thank the following people for doing a review:
Paul A Bristow
I apologize if I have overlooked anybody. Also thanks to the
*countless* people who participated in the dicsussion during the review:
none mentioned, none forgotten (as we say in Denmark).
Below follows more comments on the issues raised in the review.
Thorsten Ottosen, review manager
Detailed review comments
The general feedback was positive, with one reviewer even said he would
use the library even if it was not accepted into Boost. Experienced
boosters saw the general quality of the submission as higher than
average. There was also
some strong concerns by a few long-time boost members, most notably
because of a potential overlap with Boost.Program Options.
I think in the end it was fairly clear that the two libraries take
different approaches to the problem. Even so, the property-tree library
should clearly state the limitations of its program option parser
component and via its documentation refer to Boost.Program Options for
a more scallable solution.
There were quite a big number of people that thought the
library could and should be further polished / enhanced. There is
nothing new to this, and I hope Marcin will work hard to
incorporate/try out as many of the ideas from the review.
(There have been quite a few libraries which went through substantial
after the review and before the post-review.)
When Marcin feels his design/functionality is rock-solid, he should do
a post-review on the developer list to clear up remaining matters.
Here's a list of ideas that should be considered for the post-review:
1. documentation needs smaller topics, more examples and syntax
2. implementation: it could be a possibility to use Boost.Multi Index to
give a space-optimal implementation. We should not underestime the
tasks the library vould be used for, so space/performce does matter.
The idea of flattening queries with wildcard syntax "prop.foo.*"
might be something to look into
3. support for non-standard strings was seen as a must
4. the issue of preserving white-spaces and comments was important to
some people, which is understandable if the library is used to read
and write config files
5. serialization support would be nice
6. there should be clear statements on the limitations of the supplied
7. many would like to see the incorporation of a path concept
8. many were intersted in even more syntactic sugar to make the library
even easier to use, eg. by using (), etc cleverly.