Re: [boost] [Boost Review] Property Tree Library
I took another look at the library this morning and I agree with Jeff Garland that this library has potential. Howewver, it is hard to get my head around this library becouse it contains two very different things: 1) a recursive property-tree container and 2) six parsers to populate this container. I'm not a low-level container author so I cant speak to the merits pro/con of this implementation of a recursive property-tree. Nevertheless, I would like the review to focus on this, without regard to the parser grammers. I think that my objections could be resolved by removing the six-parsers from the review. Assuming the "property-tree" container is approved, lets schedule another review for these six-parsers. Either all of them at once, or one at a time. If the library author would be willing to delay the review the parser grammers until later this year, I might be persuaded to give this library another review.
Tom Brinkman wrote:
I took another look at the library this morning and I agree with Jeff Garland that this library has potential.
I think that my objections could be resolved by removing the six-parsers from the review. Assuming the "property-tree" container is approved, lets schedule another review for these six-parsers. Either all of them at once, or one at a time.
If the library author would be willing to delay the review the parser grammers until later this year, I might be persuaded to give this library another review.
What value does the library have, if there are no parsers to get a property tree from or to write it back to a file? -Thorsten
Thorsten Ottosen wrote:
What value does the library have, if there are no parsers to get a property tree from or to write it back to a file?
I fully agree with this point. Removing the parsers from the review makes the library essentially useless. They are an important part of the functionality the library provides. A simple string tree is not enough functionality to be relevant; if only a tree was to be submitted, I'd expect it to be a fully generic tree. Sebastian Redl
I think that my objections could be resolved by removing the six-parsers from the review. Assuming the "property-tree" container is approved, lets schedule another review for these six-parsers. Either all of them at once, or one at a time.
If the library author would be willing to delay the review the parser grammers until later this year, I might be persuaded to give this library another review.
I think I understand your point, although you did not state it directly. (Please correct me if I'm wrong) you believe basic_ptree class has some value, and meets boost quality standard. On the other hand you think that parsers that accompany it do not. If this is the case, I quite understand your point of view and the proposal you are making. I definitely agree with you that data structure is more refined and mature than the parsers. However, I'm also sure you are aware of the fact that without _any_ parsers the library is quite useless. It might still have some obscure uses, but at least 90% of it is gone. Therefore I can only agree to your proposition if at least _one_ parser is included with the library. Which one is another issue, but I believe it should be XML. More adventurous users will still be able to use rest of the parsers from boost-sandbox, while they are improved to meet boost quality standard and be reviewed. Also please note that while at the moment some parsers may look ugly, it is the implementation that is ugly, not the interface. And implementation can be safely improved while the library is already in boost. Best regards, Marcin
"Marcin Kalicinski" <kalita@poczta.onet.pl> writes:
However, I'm also sure you are aware of the fact that without _any_ parsers the library is quite useless. It might still have some obscure uses, but at least 90% of it is gone.
I think what's causing this confusion is the lack of a concise abstract or statement of the problem being addressed by this library. I mean a statement that "nails it" for people, so they instantly understand the purpose of the library. The documentation at http://kaalus.atspace.com/ptree/doc/index.html begins with a description of a data structure, but clearly, that's not what this library is about. IMO, Marcin, coming up with such a statement should be a high priority for you. -- Dave Abrahams Boost Consulting www.boost-consulting.com
The documentation at http://kaalus.atspace.com/ptree/doc/index.html begins with a description of a data structure, but clearly, that's not what this library is about.
IMO, Marcin, coming up with such a statement should be a high priority for you.
I've just made an attempt. It is posted as a reply to a new Gennadiy thread "[Property Tree] Problem domain". Best regards, Marcin
"Tom Brinkman" <reportbase@gmail.com> writes:
I took another look at the library this morning and I agree with Jeff Garland that this library has potential.
Howewver, it is hard to get my head around this library becouse it contains two very different things: 1) a recursive property-tree container and 2) six parsers to populate this container.
I'm not a low-level container author so I cant speak to the merits pro/con of this implementation of a recursive property-tree. Nevertheless, I would like the review to focus on this, without regard to the parser grammers.
I think that my objections could be resolved by removing the six-parsers from the review. Assuming the "property-tree" container is approved, lets schedule another review for these six-parsers. Either all of them at once, or one at a time.
If the library author would be willing to delay the review the parser grammers until later this year, I might be persuaded to give this library another review.
Isn't that like objecting to the serialization library on the grounds that it has code for serializing various datatypes, plus implementations of various different archive formats (parsers/generators)? I don't see anything wrong in principle with the idea that such a library should come with exemplars of the readers and writers for its data structure. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Tom Brinkman wrote:
Howewver, it is hard to get my head around this library becouse it contains two very different things: 1) a recursive property-tree container and 2) six parsers to populate this container.
This reminds me, didn't Jonathan Turkanis propose a library that handled read/write of nested containers? Does anyone else remember this? Thanks, Jeff
participants (6)
-
David Abrahams -
Jeff Flinn -
Marcin Kalicinski -
Sebastian Redl -
Thorsten Ottosen -
Tom Brinkman