Re: [boost] [property_tree] Review

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-25 16:55:28

Hi Daniel,

Thank you for your review.

>The interface is "good enough" but could be better. I believe separating
>the path handling will be a big step.

Definitely.

>Some have suggested making functions nonmembers, but I don't see that as
>an improvement. Getting and setting the contents of the tree is /the/
>use of the tree. If we don't use member functions for that, then what do
>we use them for at all?

One use of them would be to allow specialization for user-defined types. The 
same can be however achieved using extractor/inserter substitution. One 
person suggested that putting single type inside the tree should generate 
more than one node:

put("key", QPoint(10, 10))

should generate something like that:

key
{
    x "10"
    y "10"
}

This is currently not possible, because single put may only affect data of 
single node, so at best it could do that:

key "10 10"

which is indeed what I'm using in one of my projects through redefining 
stream operators for my types.

>Regarding the parsers, the metadata for XML and Windows registry could
>be better handled. These formats both have two ways of storing data
>under a node, in property_tree represented by the <xmlattr> and \values
>subtrees. Couldn't these be handled in the same way?

One of the ideas for improvement is to make metadata configurable. This is 
definitely worth doing. So that user can define where metadata will be 
stored, and even if it will be generated/parsed at all.

>Others have mentioned it needs work, especially in the rationale. Given
>the confusion at the start of the review period this is clearly the case.

I'm going to port documentation to QuickBook. I've tried once, but I could 
not make the toolchain working neither under Windows nor Cygwin, so I 
reverted to plain old HTML. With hindsight, this might have been a 
mistake...

 > - was the library's design flexible enough? If not, how would you
 > suggest it should be redesigned to broaden its scope of use?

>It was "flexible enough", but I would prefer if it were more flexible.
>In particular, I definitely think path handling should be separated out
>from the accessor functions, but I believe this is already in
>progress(?)

Waiting for the review to end before start working on it. As I said before, 
no matter if the library is accepted now or not, I will continue working on 
it. After I read all the nice ideas people have about it, I feel it can be 
made a lot better.

Best regards,
Marcin