Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-10-18 13:37:33

--- In boost_at_[hidden], "David Abrahams" <abrahams_at_m...> wrote:
> ----- Original Message -----
> From: "William Kempf" <sirwillard_at_m...>
> > I really don't intend to criticize here, because the library is
> > vastly important and useful to some people (I don't know python
> > so I'm not one of them, but I'm not letting my lack of knowledge
> > cloud what I'm saying). However, I thought one of the major
goals of
> > Boost was to develop C++ libraries that through evolution and use
> > might be considered with the next language standard? If I'm right
> > about that goal, py_cpp doesn't fit with Boost.
> I hope my counterargument from previous emails covers this.

It does, and honestly I have very little opinion here. I see both
sides of the issue on the appropriateness of py_cpp in Boost.
> > So long as the library is complete at time of submission then I
> > that just because there's further extensions planned is not a
> > to delay submission. I hope to use a similar tactic with the
> > thread library, submitting a core set of features that will allow
> > developers to expand into more complex concepts.
> Then we have to define "complete". Py_cpp was complete in that it
was useful
> and relatively bug-free upon submission. There were also a lot of
> enhancements waiting to be made.

I think I might have been misunderstood here. I agree with you. I
think py_cpp was "complete" enough for submission. I was arguing
against the general idea of not including a library that has obvious
room for extensions.
> > > > It seems like once in Boost this library might still undergo
> > significant
> > > > changes on a weekly basis. Perhaps I'm wrong on this, but
> > > > comments and added features during the review period have
> > > > concerned me.
> > >
> > > Is the concern that rapid improvements to a single library might
> > cost boost
> > > some credibility?
> >
> > I'd say that's a concern, but it doesn't lead to concluding that a
> > library not be included just because extensions are planned.
> > important is that the extensions are carefully thought out and go
> > through a seperate review period.
> That is /not/ part of the boost protocol as I understand it (though
I notice
> the online documentation gets very fuzzy at this point). Once it is
> accepted, changes to a library do not undergo the same formal review
> process. Maybe we should change that, but IMO it might impede

Simple changes, such as minor extensions, bug fixes and optimizations
are easy to deal with by simply allowing the "maintainer" to update
the CVS repository as he sees fit. However, major extensions to an
existing library should go through formal review, IMHO. Otherwise it
would be possible for a developer to submit a simple library, such as
a date class, and after formal review "extend" the code to include
full network time protocol socket support, including an iostreams
based socket class, with no formal review of the obviously unrelated
and vastly important concepts.

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at