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