Re: [boost] [property tree][review]

From: Matias Capeletto (matias.capeletto_at_[hidden])
Date: 2006-04-24 23:05:04

Marcin wrote:
> Thank you for the time you took to review the library. Although your vote is
> no, you presented an interesting alternative to current syntax, and also to
> other proposed syntaxes. I was unaware of the potential that operator [] had
> in the context of ptree when coupled with overloaded, templated conversion
> operator and "ghost nodes". Originally I dismissed it, because it was
> limited to one argument, and also because I'm not a great fan of overusing
> operator overloading.
> I now see it as another variant of ptree syntax revolution, besides path
> class proposed by Matias Capeletto and Jeff Flinn.

I first have to state that i am not married with the operator/
solution, i just want to show some others conclusions that may help to
redesigned the interface...

The first thing is that i like the operator[] overload for ptree. I
dont see it however as another variant to the path+operator/ proposal,
but as a complementary sintaxis. I think of operator[] as a 'beatifull
sintaxis' option to the get_child() function. IMO nobody will say that
the following line...

int i = mymap.get_child("fee").get_child("far").get_child("thumb").get(3);

is better expressed by...

int i = mymap["fee"]["far"]["thumb"].get(3);

But if we want to support other things by means of this solution, like
for example indexing, we will have to do something like...

int i = mymap["fee"]["far",2].get(3);

IMO this looks elegant, but because the operator[] return a ptree
object, we just add another function to the ptree interface to support
it. Every new feature we want to add to ptree in order to make it
evolve to better things... we will need to add members in it.

This is where the path concept will allow some magic. IMO the 'most'
important property of the having a path class is the orthogonality
that it introduce. Iterate with a path in a ptree and constructing a
path are now two clearly separated process.

I want to make this clear so i will redundantly state it:
(A) Iterate in the ptree structure
(B) Construct the path

In the operator[] this two process are tighly coupled, we are in fact
constructing the path 'by' iterating in the tree. I like this, i think
i will use it for certain things, specially in recursive algorithms
over the ptree. Is very efficient in this cases because we dont need
to begin from the head of the ptree every time, we can save a
reference to one of the ptree that is returned in the middle and use
it.

The orthogonality of the path class aliviate the ptree from
constructing the path, now ptree only define one function that receive
a path (we get rid of the get('/',key) familiy of functions). On the
other hand we now have the possibility of constructing the path with
different aproachs as we have show in others threads.
We get 'x' separator support, indexing support, locale support, etc
with out polute the ptree interface.

What is more important, if Marcin makes it easy to define different
path classes (i am confident that he will be able to do it) i will
apreciate to have...

using xml::comment;
xml_path p;
mymap.get( p / "fee" / "far" / "thumb )      // == get( "fee.far.thumb" )
mymap.get( p / "fee" / "far" + "name" )    // == get( "fee.far.<xmlattr>.name" )
mymap.get( p / "fee" / "far" + comment ) // == get( "fee.far.<xmlcomment>" )

the paths will asser if after the + is another / key sequence.

And finally we can support something that i think everybody will just
love to be able to do...

typedef xContainer<key> container;

container c;
...
ptree::path p;
mymap.get( p / "debug" / ptree::path( c.begin() , c.end() ) / "name" );

With this we now have the entire stl (and boost) containers playing
along our lines!

things can not get better... ( or can? this is, i think, the fifht
message since Marcin says: "And the picture will hopely be complete"
and beatifull things can not stopped to pop from the base of ptree.)