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

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-21 16:45:41

Hi Andy,

First of all, sorry I did not reply sooner. The interest in the library is 
quite large and there is only that many posts I can answer per second ;-) 
Additionally, I spent most of today on ACCU conference, and so have 
developed a huge backlog.

> AFAICS the current ptree could be a refinement of a a generic tree 
> container,
> however the current design of ptree is not so defined and its probably not 
> going
> to be possible to 'reverse engineer' genericity from the current design.

I think generic tree is a material for another library. The question if 
property_tree should be based on one is just an implementation issue, not of 
much interest to users.

The biggest virtue of property_tree is easy to use interface. If we try to 
make generic tree of it, it will be compromised. This should not happen, 
because people will then prefer to use Expat or MSXML instead.

> [...] ptree doesnt distinguish the concepts of a branch and a leaf. It is
> possible to imagine an alternative design in which a branch can be 
> iterated over
> whereas a leaf cannot, and the 'data' in a branch is a container of nodes
> whereas the data in a leaf is not.

I never before thought of using polymorphism to distinguish between branch 
and leaf nodes. The reason is I never saw need to. For example this would 
imply that as soon as you add children to leaf it changes type (i.e. must be 
destroyed and reconstructed - what happens to pointers/references somebody 
may be holding?). My feeling is that interface would get quite muddled if I 
adopted that sort of approach.

> But it would be interesting to know why you have chosen this design over 
> others.
> That is not stated in the docs AFAICS. It would help when I wanted to use 
> such a
> library because it could help me to make a fast decisison as to whether it 
> was
> suitable.

Main reason was existing practice. I used this type of container for many 
years before I even considered writing any docs, let alone submitting it to 
boost. I had quite a lot of experience where and how it could be used. Plus 
the implementation I had - refined over several years - was starting to look 
mature. I knew it had general value, because it helped me on many projects.

And the short answer is I never considered completely different 
implementation because the one I had worked, and I had other things to worry 
about :-)

>BTW the current 'Rationale' section looks more like a 'FAQ' section
> FWIW.

That's right. I think it was bigger in the past, but many explanations 
proved to be ill thought out, and I had to remove them ;-) If this continues 
I might be forced to remove this section completely.

>> Library would need some sort of path parsing policy [...]
>
> One option I envisage is to make a symbol table, where each new string 
> token
> encountered is given an integer id, and only the id's are stored in the 
> tree.
> The intent being to speed up key lookups. In this case a path to a node 
> consists
> of a linear container (e.g a vector) of integer ids.

I think this could be done if I implement key policies. You just define key 
type to be a vector and supply appropriate head/tail functions (which would 
be trivial in this case).

Thank you,
Marcin