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

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-05-22 17:39:49

> [...] Hope you don't mind if I add a couple of wishes/suggestions based on 
> my recent usage:

You're very welcome! Suggestions based on real-life experience are the most 
valuable. As you can see below I agree with most of your comments.

> - 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.

One problem with it is that different nodes in the same hierarchy may end up 
with different separators. Another problem is that every node will store a 
copy of the separator, a waste of memory.

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

Yes, definitely. No worries :-) Judging by people's comments this has been 
one of the biggest selling points of the library. Judging by my experience 
with ptree, string paths are very useful. While path classes may provide 
additional flexibility and performance where it is needed, string paths will 
continue  to provide simplicity and ease of use in a majority of real life 
cases. How exactly this will be implemented is another issue.

> - 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.

If done, this should return a path object which could optionally be turned 
into a string if needed. But it is dependent on having parent data member.

> - Add 'parent()' method.

The reason why there is no parent() is that originally ptree held children 
by pointers, not by values. This allowed, among other things, storing a 
single child in many parents. Obviously, there was no good way to implement 
parent() then, so it wasn't there. I dropped the pointers long time ago and 
replaced them with values, because they were causing too much trouble and 
some of the advantages they provided could be simulated another way. Now 
that the tree only has one parent, parent() can be done easily. At the 
moment I don't see any reason it should not be done.

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

Yes, if parent() is implemented, paths must support some sort of 
tree-walking.

> - I'm personally not found of e.g. operator[] acting the way as the 
> std::map subscription operator.

I've done an experiment with operator [] recently.  John Maddock presented 
it quite nicely, proxy objects for nonexisting nodes, templated conversion 
operators, etc., so I didn't have to do much thinking. It is very clever and 
works, at least as far as I implemented it. But after the experiment, I 
think it is actually _too_ clever. In case of ptree, I believe operator [] 
based interface is inferior to named functions. The reason is readability. 
There are too many operations one can do on a node to cram them all into a 
single-parameter operator. From my experiment, it looked more like an 
exercise in C++ aerobatics, than a robust solution. Concluding, it has its 
virtues, and I don't shelve it yet, but I must try something else first.

Regards,
Marcin