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

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-20 15:56:17

>> The biggest difference is that property_tree is a DOM, not a linear 
>> structure.
>
> In a big part it's implementation detail. I might as well keep all the 
> parameter in single list with names like "a.b.c.d". Though I agree that 
> variable_map could be done better.

No, this is not implementation detail. This is a fundamental difference. Of 
course, you can have PO store options in form of a.b.c.d, but that does not 
make it hierarchical. How do you make a copy of a branch and attach it 
somewhere else? How do you remove a branch? How do you take only one branch 
and make another options structure of it? All these operations would be 
extremely cumbersome, not to say that also possibly inefficient, using 
linear structure.

>> [...]
>> With program options you would have to teach my_component extract values 
>> from whatever place they are in config file(s).
>>
>> Other things that are not supported by program_options:
>>
>> - writing configuration
>
> Why would I need that? Or rather in how many instances I would need that?

I think this type of usage is rather common, at least the way I used 
property tree relied heavily on these features. For example I used it as a 
primitive serialization library where files containing objects were human 
creatable. I had an application which had GUI to manipulate these objects, 
and allowed to save them back again to files. All I/O was done using 
property tree.

>> - XML, JSON, INI, Windows registry parsing out of the box
>
> You could implement them as an add-ons.

How can you present hierarchical structure like XML or JSON as a linear 
string of options? A string of a.b.c.d -form keys is not extremely useful.

>> Also, I think that in simple cases, syntax offered by property_tree is 
>> simpler and has less steep learning curve.
> It's matter of opinion and again it's just  PO issue.

Possibly, but it also supports options descriptions and notifications. These 
do not belong to property_tree. For example descriptions would make little 
sense when parsing XML file.

> Essentially it's unusable for anything any different for one rigid format 
> you chose.

That format covers most simple command-lines I have seen. It is not enough 
to implement a command line for a tool like gcc, but then it is not intended 
to. If you are implementing a copy utility that takes two filenames and 
several flags, (like -r, -m etc.), it works.

>>> 9. Access interface are lacking. If I got string identify subsystem and 
>>> string that identify parameter separately why do I need to concatenate 
>>> them to get to the value
>>
>> You don't have to concatenate them:
>>
>> int subsystem_parameter = 
>> pt.get_child("subsystem").get<int>("parameter");
>
> And if I have more levels?
>
> string trace_config = 
> pt.get_child("MyLib").get("debug").get("trace").get("config");
>
> I would rather prefer
>
> string trace_config = pt.get("MyLib", "debug", "trace", "config" );

This is a matter of taste, in my opinion both are similar. But would you 
implement your version using variadic arguments or by supplying 
implementations up to N parameters?

>> I don't see a way I could simplify it considerably. If you see, please 
>> let me know how.
> I did. See config_file.hpp ib Boost.Test code base.

I'll definitely have a look.

Best regards,
Marcin