Re: py_cpp

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 
yet,
> > so I'm not one of them, but I'm not letting my lack of knowledge 
here
> > 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 
agree
> > that just because there's further extensions planned is not a 
reason
> > to delay submission.  I hope to use a similar tactic with the 
Boost
> > 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 
obvious
> 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 
previous
> > > > comments and added features during the review period have 
slightly
> > > > 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.  
What's
> > 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 
progress.

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