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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-04-22 08:00:22

Marcin Kalicinski wrote:

Marcin, consider leaving the attribution intact, as I believe Dave has 
already requested.

>> [...] that's the main problem with this submission. Instead of
>> clearly specified problem domain and design that address issue in
>> this domain, you present some mixture of half-good components each
>> with unclear advantages over existing dedicated solution in each
>> respective area. [...] We do need good tree storage. We do need better 
>> runtime parameters
>> support library (IMO). We already have quite powerful solution for
>> permanent storage support, but we could use more archive formats for
>> it. What you propose is none of it.
>
> I'm sure you will agree that ptree is different from serialization.
> If you don't agree, read some of quite interesting posts by Ivan
> Vecerina. The main difference is that serialization lib is _only_
> about translation of some C++ structures to/from a string of bytes.

This is not entirely correct, even though Robert himself states so. The 
serialization library has two separate parts: the first part translates a 
C++ structure into a sequence of archive calls, the second part (the 
archive) translates this sequence to either a string of bytes or something 
else (a property tree, for example.)

The problem (in this context) with the serialization library is that its 
first part inserts semi-opaque metadata into the stream which leads to the 
output being not particularly well suited for human-readable and editable 
configuration files.

Anyway, as I'm already in the thread...

In my opinion, the property tree library is at or above the average Boost 
quality and should be accepted. It is obvious (at least from a quick reading 
of the documentation) that it has a reasonably clear purpose and fulfills 
this purpose pretty well.

There is a significant overlap with other existing and future (string_to) 
Boost components, but the overlap is inherent in the design and cannot be 
eliminated without making the library something else entirely.

It is evident that the library is string-based at its heart and the 
parameterization on arbitrary key or value types is not yet a first-class 
citizen. It is likely that the interface needs to evolve a bit in this area. 
As an example, tree structures that hold intrusive_ptr<element> and can be 
indexed by path are very useful. On the other hand, we should evaluate 
whether a non-string key type works at all, since most interesting library 
features don't seem to be available, it degenerates into the simple struct 
shown at the start of the tutorial.

I very much do not like the 'traits' policy parameter (which is not a traits 
class at all, even though basic_string says so.) Do not deceive the users 
that you have a single axis of parameterization when in fact you have six, 
some of them redundant, some of them more useful than others. basic_ptree 
should be templatized on key, data, ordering, inserter and extractor, not 
necessarily in that order. The default arguments should be clearly 
documented and useful outside of the library context. It should be possible 
to eliminate char_type, but I'm not 100% positive about it.

One easy way to eliminate the distinct separator methods would be to make 
the path syntax always start with a separator. If we really want a 
non-string key type, one option I see is to use vector<key_type> as a path.

It might be useful to make the library take filesystem paths, getting the 
operator/ for free.

The INI parser could probably support more than one level by using 
l1.l2.l3.l4 as key (with an appropriate escaping scheme for the real dot.)