Re: [boost] [Boost Review] Property Tree Library accepted

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-05-22 02:46:44

Marcin,

comments below.

Marcin Kalicinski wrote:
> Dear Everybody,
>
> It was a real pleasure to read this post. I am sure there are many
> people who feel the library needs polishing and rethinking in some areas. 
> A
> lot of interesting ideas were proposed during the review, and I
> already started work on the next revision. I hope the changes I intend to 
> do will
> make these people less concerned about the quality and usefulness of
> the library, while they will not detract from what other people found
> valuable.
> Below is a (possibly incomplete) list of improvements I intend to add
> in future revisions:
>
> - path class, orthogonal to the tree
> - configurable location of metadata generated by the parsers (e.g. XML
> attrributes information). It may be possible to achieve that for free
> with paths
> - generation of comments / layout metadata by parsers
> - splitting traits
> - support for using custom types for keys, again path class looks
> like a solution
> - documentation rewrite to QuickBook, and enhancements (thanks to
> Charles Brockman who provided tons of English-related corrections)

I unfortunately did not have the time to review your library, even though I 
knew I would try to use it in my configuration file handling stuff. Hope you 
don't mind if I add a couple of wishes/suggestions based on my recent usage:

- It should be possible pass the path separator char to the ctor, which then 
should be used as the default for all operations. This wish might be partly 
invalidated if/when you implement a path class. I still haven't stumbled 
upon a use case where different path separators need to be used within the 
same property tree.

- Preserve the possibility (in path class or wherever) to use a plain text 
string to specifiy a path. Please.

- Add a 'name()/full_name()' method to the interface; the name() method 
would return the current tree 'leaf' name and the full_name() returns the 
complete path from the root.

- Add 'parent()' method.

- Add support for relative paths; e.g. ptree::get("../sibling/arg")

- I'm personally not found of e.g. operator[] acting the way as the std::map 
subscription operator. If you implement operator overloading for the path 
handling, please support failures being reported if the path elements does 
not exist (via supplied error handling policy or similar).

Thanks for an already very usable library.

Regards / Johan