"Boris" <boriss@web.de> wrote in message news:e2i1qg$or0$1@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