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

From: Matias Capeletto (matias.capeletto_at_[hidden])
Date: 2006-04-20 19:39:31

First of all i want to state that i really like the functionality and
interface that ptree offer.
As said before the easy of use of this library and the clean code that it
generates are impressive.

If we have to make a change that compromise the interface i think we
are going to kill it.

Although, i have a proposal that i think will:
a) preserve the actual interface.
b) add a lot of functionality with the same easy of use
c) give better performance

I think that we are missing the big picture discussing about . or / in
the get-put functions.
The fact is that the library implements the path search directly, and
this is a very nice
spot to insert one level more of abstraction. A path can be view as a
single linked list of keys,
the "xxx.yyy.zzz" is only one way to representing it. (a very
convenient way i have to said)

Think what we could gain if we define a path concept here (i have read
all the code of the
library and it is a straight forward change to it). The get/put
function will receive as a
parameter a path, insted of a '.' concatenated key.

First we support conversion from '.' concatenate keys to path... Now
we can use the ptree
in the same way as it is now. Next we support operator / for making the path.
The thing is that with a path concept in the middle we can now use the
following alternative idioms

// Standard conversion
// Very clean and the path can be formatted as a hole or can be read
from a file.
{
        ptree data;
        data.put( "debug.info.count", 3 );
}

// Other separation parameter
{
        ptree data;
        ptree::path p(' ');
        data.put( p / "debug info count", 3 );
        
        // space used as a separator, note that this is cleanner than
        // pass ' ' as a parameter, and half of the get-put functions in the
        // ptree implementation dissapear
}

// Can have a path with '.', '/', ' ' or any other character in the keys
{
        ptree data;
        ptree::path p;
        data.put( p / "debug" / "info" / "count", 3 );
        data.put( p / "d.e.b.u.g" / "i n f o" / "s.t.u.f.f", 10 );
}

// Can use variables without the needs of special concatenation care
// Observe we can mix concatenation with operator/
{
        struct Human {string name; int age; }; typedef vector<Human> Humans;
        Humans humans;
        ...
        ptree data;
        ptree::path p( '/' );
        for( Humans::iterator h = humans.begin(), end = humans.end(); h != end; h++ )
        {
                data.put( p / h->name / "info/age" , h->age );
        }
}

// And finally other things can easily be supported
// As an example, suppose we need to group e-mails by providers
{
        struct email_info { string direction; string owner }; typedef
list<email_info> eList;
        eList email;
        ...
        ptree data;
        ptree::reverse_path p('@');
        for( eList::iterator e = email.begin(), end = email.end(); e != end; e++ )
        {
                data.put( p / i->direction , i->owner );
        }

        // And now we can ask to the tree things like
        data.count( p / "gmail.com" );

        // Or save this info grouped in an xml!
}

// Now we can consistenly support other key types
{
        intpTree ipData;
        intptree::path p;
        ipData.put( p / 140 / 123 / 25 / 10 , "home" )
}

I think that this flexibility is great and i cant see any major
drawback of adding it to ptree.
Best of all, programs that used the old version will compile without any change.
The lookup performance is better because you don't have to make many copies of
the '.' concatenated key tails.
And if the operator/ sintaxis is used the performance is even better.
Some implementations details could change, in my head the put/get
function pop the
head of the path list while they are using it, and as a post condition
always return an
empty path. I know it is not very usual, and other more standard way
of doing this
could be worked it out.
Ok, that is it... i hope others like this flexibility too.

 * What is your evaluation of the design?
I really like it, specially the easy of use.
I would add the path abstraction to boost ptree flexibility :)
Only one thing, i dont like to pass a bool as a function parameter
because i always forget what was intend for. You use this aproach to
specify if the path must be overwritted. I thinked about it and not
reach to any other good sintaxis, but it is there.

 * What is your evaluation of the potential usefulness of the library?
Very, very high
I think this library will be widely used.

 * Did you try to use the library? With what compiler? Did you have
any problems?
VS2005, works very nice...

 * How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
Read the documentation, study all the .hpp and think about it quite a lot.

 * Do you think the library should be accepted as a Boost library?
Yes, i will encourage other to use it too.

- was the library's performance good enough? If not, can you suggest
improvements?
 incorporate path concept

- was the library's design flexible enough? If not, how would you
suggest it should be redesigned to broaden its scope of use?
 again, the path concept

regards
Matias Capeletto
Argentina

PD: Congratulations to the library creator! it is very light-weight
and powerfull...
PD: this is my first libray revision... sorry if there is another
aproach to present it.