Boost logo

Boost :

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-04-23 03:07:59


Tom Brinkman wrote:
> Sorry, But I cant follow you in the thread so I have to put this at the top
> level of the thread. I am not at home right now.
>

At least your still in the main thread :-)

Why not use ThunderBird + gmane?

>>I understood it perfectly well. However, you also stated that the
>>parsers should come in at a later point. Thus my point still applies, if
>>only for limited time. However, that time is crucial. If there is a
>>Boost release (1.35) that includes the tree, but not the parser, people
>>might get used to that "useless property_tree thing" and not care to
>>look at its improved value in 1.36. Bad reputations tend to stick.
>
>
> Poor points. Getting this library thing ready by version 1.35 or any other
> version is my last concern. I want it to be correct.

Right.

> Its not acceptable
> that that this fairly large library will not get the full review that is
> necessary for a boost library. The scope of this library is too diverse for
> it that too occur in only a 10 day review period.

You're allowed to think tbat. But the period itself is not the only and
best meassure. I value the number of reviews and their depth more.

Thats said, if the need arises, I hope we can extend the review period a
few days.

> It is very, very common
> for libraries to need a second or even a third review. I think that this
> library falls in that category of libraries that will need multiple reviews.

You're also allowed to think that.

>>Also, the way I understood your post, your objection to the parsers was
>>that they are a completely separate thing from the tree and thus should
>>not be reviewed together. I find this objection simply wrong. The
>>parsers are a very important part of the property_tree library, and IMO
>>it's just its inappropriate name that makes them seem misplaced.
>
>
> As this seems to be opinion that you share with one or two others, please
> educate me. Why does the "property tree" require a parser. I just dont get
> it. How is the "property tree" container different from the vector and map
> containers, which almost certainly did not have parsers included along with
> them when they were added to the standard. What makes the "property tree"
> different from other containers that dont require parsers. I dont recall a
> single example of a container in C++ that had to have a parser.

To me you have completely misunderstood the library's purpose.

> I suspect that those of you who want the parsers included with this library
> are just trying to sneek an XML parser through the review process without a
> full review. Please tell me that I'm wrong on this point.

For one, it is not a full xml-parser. I still hope that somebody
will submit a mean SAX/DOM level 1,2,3 or whatever parser. There is
barely no overlap with this library: the focus here is on simplicity
and usability. The focus on an xml-library would be, well, full
xml-support and lousy interfaces.

> This library will eventually get accepted, I'm fairly sure of that, possibly
> even portions of the library will be approved this time around. What is
> your rush to get this one through. Lets take our time and get it right.

Let's see how the review unfolds.

And let's hear more about what is wrong with it.

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk