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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-04-20 17:02:56

"Marcin Kalicinski" <kalita_at_[hidden]> wrote in message 
news:e28p14$mdt$1_at_sea.gmane.org...
>>> 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,

You got me convinced. PO indeed shoudld be implemented differently ;)

> not to say that also possibly inefficient, using linear structure.

Who cares?

>>> [...]
>>> 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.

This type of usage require different tools. I would use Serialization lib 
for that.

>>> - 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.

They would make a lot of sence. Especially when you will start producing an 
error message if some required property is missing.

>> 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.

Exactly. It does not stand a comparison with another existing solution for 
CLA parsing..

Gennadiy