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