Re: [boost] [Property Tree]Problem domain

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-24 05:32:54

"Boris" <boriss_at_[hidden]> wrote in message 
news:e2i1qg$or0$1_at_sea.gmane.org...
: Gennadiy Rozental wrote:
: > [...] Option 3:
: > Generic facility to manipulate hieratical data with permanent storage
: > support.
: > ==========================
: >
: > My main objection in this domain is that author decided that his
: > particular data structure would be good enough for all usages. The
: > word "particular" is main offender here.  I don't believe any
: > "particular" data structure would be good enough. Some novice users 
may
: > use simple structure with class
: > Leaf and class Brunch. Some prefer generic tree one. Some need
: > compile time polymorphism only. Some could use runtime one. Some
: > Would use boost::variant as value.
: >  IMO save/load side of the library like this would need to be made to
: > work with any data structure satisfying some concept. The same
: > applies to access methods (This is the reason why you need to switch
: > to free function based interfaces)
:
: I agree. That's why I asked in another thread if the access methods are
: loosely or tightly coupled with property_tree. Marcin himself wrote in
: another message that using property_tree "is a matter of internal
: implementation". Adding some more flexibility here would be nice and 
seems
: to be possible.

I agree as well.

As much as I initially disliked the ptree data structure (I am used to
a polymorphic record/array/leaf node), I think that it has the true
merit of providing a reasonable common in-memory representation for
a variety of back-ends formats (XML, JSON, MSWin registry, Init, ...)
I would have liked to see a class that enforces a longer list of
invariants (e.g. enforcing only pure array//record//leaf nodes),
but this would restrict the range of the supported formats.

I think that by introducing this library into boost, we provide a
platform for further developments, with a good potential for
synergy with po & s11n.

However, I cannot agree to see this common in-memory representation
burdened and crippled by what is currently a too narrow and too
limited value conversion interface.  So my vote is to keep this value
conversion & path handling separate: either in a distinct wrapper
(path parsing & value conversion) class, or as free functions.

If this requires delaying the adoption of ptree, or adopting it
without a value conversion interface, then so be it.
But as a minimal change least-effort option, moving the member
functions out into a dedicated namespace would be acceptable to me.

Of course this is just my vote, with all due respect to
Marcin's excellent work and valuable contribution.

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