Re: [boost] [1.36.0] Libraries with unmerged changes?

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-15 17:50:01

Emil Dotchevski wrote:

>> The whole concept of a library is that it has established
>> interface and semantics that users of the library can depend upon.
>> Without this, libraries are useless. One can't write code based on
>> libraries whose interface and/or semantics are changing without
>> notice.
>
> If that was true, nobody would be using Boost. :)

First of all, most of the boost library authors are concienscious
about maintaining the the imutability of the interface and sematics.

In part this is due to the fact that boost requires documentation
of the interface and semantics. This alone is helpful in
diminishing the problem.

My complaint is that the testing procedures accomodates silent
breaking of interface and sematics - moving the burden from the
author making the change to all the users of his library.  This is
a bad thing and amounts to a breach of trust between library
authors and users.  It hurts Boost.

> It's a fact, Boost libraries evolve and interfaces and implementations
> change all the time.

Not very often - and when they redefine the original interface and/or
sematics they break all user programs (and other libraries which
depend upon them).  This is a break of

> You can argue that the changes are minor, but as
> you know they're significant enough to break tests in other libraries.

LOL, I'm arguing that they are NOT minor.

>>> For example, the Exception library
>>> depends on intrusive_ptr. The only way to make it not depend on
>>> intrusive_ptr is to not use it (duh.)
>>
>> Nope - The exception library should depend upon the intrusive_ptr
>> library interface and semantics which should never change.(duh.)
>

> I am on the fence actually. It was a difficult decision for me, to
> depend on intrusive_ptr. Ideally it wouldn't change but the reality is
> that it might. And if Boost Exception wouldn't benefit from a future
> improvement in intrusive_ptr, it's perhaps better not to depend on it,
> given how simple it is to "reinvent the wheel" in this particular
> case.

and your point is?  intrusive_ptr interface and sematics might
change you shouldn't rely on it?  If this is true of course you
can't rely on it.  THAT's my point.  I think we in agreement
here.

> We have plenty of examples for Boost libraries changing for the
> better;

LOL - a distinction has to be made between interface/semantics
vs implemenation.  Implementations can and should evolve.
Interface/semantics cannot and should not except in the rarest
of circumstances (auto_ptr, vector<bit>).

> Boost Function changed between 1.35 and 1.36, both in terms of its
> interface and semantics. The new allocator support is better but we
> know it is a breaking change.

If this indeed occurred, it was an error on the part of the author
and he's just told users - "you're all working for me now".  Not
a smart move if he wants to see his library widely used.

> Another example, shared_ptr now supports
> aliasing, which means that other Boost libraries that use aliasing
> can't be tested against 1.35.

aaaaa - other boost libraries which used alias before it
was implemented in shared_ptr.  That would be quite a trick.
New features an be added to a libray interface and semantics
without breaking the old ones.  The next version would include
new tests and demos and documentation.  The next version
would depend upon only on those features in existence
at the time the extension was written.  - unless the library
author is psychic.

> Had boost::function and boost::shared_ptr been frozen, we wouldn't
> have been able to make these improvements. If I have to pick between
> the improvements and the benefits of freezing these two Boost
> libraries in particular, I choose the improvements (with all the
> consequences, including release and testing difficulties.)

oh - don't forget about the difficulties of your current users who
now have to adjust their apps to accomodate a new library interface.

This is an error.  If you want new semantics/interface - give them
new names and leave the old one's in.

>>> Same with Boost Config: having a single configuration point is
>>> convenient but the price of that convenience is coupling.
>>
>> That is a very high a price to pay and should only be paid
>> in extraordinary circumstances.  In this particular case, the
>> change should have been incorporated in the "next release"
>> then it would have been detected when the "next release"
>> is tested.  At that point concensus would be built for either
>> backing out the change, or rippling through the interface
>> change to all libraries which depend upon it.  During this
>> period - and only during this period - the "next release"
>> would be unstable and not a candidate for a release
>> package.
>

> Yes, but you are assuming that since the period of unstableness is
> limited in time,

I would be much shorter than the current one.

> it's also limited in scope.

That's why it would be shorter time.

> For your approach to be
> practical, we need more formal classification of changes, I think.

We only need two classificaitons:  Either a change breaks
interface/sematics or it doesn't.  Every change fits into one of
these two clasifications.

>>> I think that it would work better if we had less coupling in
>>> Boost (I'm not sure if that's possible/practical, though.)
>>
>> LOL - Boost and other libaries are successful in inverse
>> proportion to the coupling to other libraries.
>
> Boost is not a library, it's a collection of libraries.

ALL the more reason for LESS couplilng.

 > I'm talking
> about dependencies between Boost libraries, not about Boost depending
> on external libraries

I'm talking about the concept of libraries in general - of which boost
is an example.

>  (à propos, one of the arguments against using
> Boost is that it's very difficult to use this or that Boost library
> without introducing a defacto dependency on all of Boost.)

LOL - avoiding the kind of coupling that our test system
encourges is part of this problem.

>
>> Suppose STL changed with every release - would it not
>> be effectively useless?
>
> No, but I agree that it would be a lot less useful.

LOL - hmmm alot less useful but better than useless? Care
to quantify that?

> Also, the price of the stable STL is that we have to live with its
> problems. A good example is the broken allocator semantics of STL
> containers.

But at least they're not changing while we're not looking.

>> Obviously there will be rare occasions when interface
>> and/or sematics of a library change (auto_pointer) when
>> things like design errors are discovered. But these situations
>> should occur only vary rarely.

> The question is what to do when such changes in Boost libraries occur,

My proposals effectively separate issues in to two classes.  Breakage
of interface/sematics and testing of libraries on various platoforms.
The current system lumps them together in to one large stew which
obsucates the problem and wastes a lot of time.

> because the reality is that (very often) they do.

I don't think its that often.  Its just that when it does, it creates a big
pain in the neck for lots of people

************************

And now while we're at it.  The test/build system should be stable during 
testing as well.
Libraries which use the Boost Test shouldn't be using the current "in 
development" versions
to test.  This amounts to having all the boost developer's be guinea pigs 
before the component
has been exhaustively tested by the author.  The same goes for bjam, process 
jam log etc.
My proposal would also address this since test of each library would occur 
against
only a "known good" set of libraries and tools.

Robert Ramey