From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-05-22 02:46:44
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.
> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk