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

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-20 08:00:33

"Jeff Flinn" <TriumphSprint2000_at_[hidden]> wrote in message 
news:e27qih$65r$1_at_sea.gmane.org...
: Ivan Vecerina wrote:
: > "Sebastian Redl" <sebastian.redl_at_[hidden]> wrote in message
: > news:44463E63.6030703_at_getdesigned.at...
: >> Marcin Kalicinski wrote:
: >>
: >>> Agreed. I thought about it before, and came to a conclusion that
: >>> the best way to implement it is to use preprocessor constant to
: >>> allow user specify default separator, e.g.
: >>> BOOST_PROPERTY_TREE_SEPARATOR.
: >>>
: >>>
: >> I disagree. I think this should be a runtime per-tree setting, not
: >> something set at compile time. I also think it would be quite
: >> trivial to do.
: >
: > Why do you care to have this as a per-tree setting ???
: >
: > So now, say that someone writes a library function to read a ptree
: > into a  struct EmployeeInfo.  Unless this function explicitly
: > specifies the separator at every call, it will fail if you pass
: > it a tree that is configured to use a different separator ?
: >
: > I'd much rather have a universal default ( . or / ), guaranteed,
: > that I can use in all my "item paths".
: > And maybe, if there is a reason to think that it will be useful,
: > the ability to specify a custom separator for a call. But
: > what is the point?
:
: What if the keys contain '.' or '/'?

Then the function that uses such a key can explicitly specify
a different separator, or use a different accessor function.
One could also choose to provide an escaping mechanism within
the path.  But in the first place, ptree will never be able to
open just any XML/whatever file - users of it can also adapt.
Do you need to have built-in support for every corner case ?

But the key point is:  the function that uses a path string also
knows which separator it intended to use in its notation.  Storing
the separator as a property of the tree goes against encapsulation.

I would just pick a default separator. I don't care which choice
is made, but '/' makes sense.

Also implement path-access as non-member functions, so users
are free to choose an path-specification approach if desired.
And how about supporting array indexing in the path syntax ?

Ivan
-- 
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form