Boost logo

Boost :

Subject: Re: [boost] Breaking existing libraries
From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-12-02 18:25:26

David Abrahams wrote:

> Of course backward compatibility is desirable,
> but maintaining it rigidly prevents forward progress.

This is one side of the medal.
Don't call it backward compatibility but maturity
and stability. The aim of the critique probably is
clear distinction in maturity and stability for
different parts of boost.

In case of spirit we have the following situation:
spirit2x (nomen est omen) is a *completely*
different library with a completely different
interface written on a different base and a really
inferior stability compared to spirit 1
(Even though it is ultimate high quality code and
I begin to like it).
Now that I became aware of what it means for me that
good old spirit gets dropped and reworked this way
I wish its new name was boost::ghost or whatever and
spirit left in the state of 1.34.1:
It works, it is fine, it has - of course - some limitations.
So what? The parsers I have written with spirit are
those parts of my code I never had to touch again
(except once, see below).
Sometimes no change is good.
Also because I know most of spirit-1 oddities by heart
and can fiddle small parsers within minutes I do not want
to switch to 2x now.
I acknowledge the hard work done to keep spirit1 in
the distro, but I still dislike the way it was solved,
because I'd prefer spirit-1 to be a first class citizen
for at least 3 more years.

> Judicious breakage does not necessarily mean that
> the library is "experimental" in any meaningful way.

Yes and no.
If you touch it you probably will break one thing or
another (and agile as you are fix it in 5 minutes after
bug report).

IMHO this also is a communication issue.
On this list several people (me included) have already
proposed to introduce stability labels.
E.g. spirit2x *should* be tagged highly experimental
pre-alpha code *despite* Joel's programming skills until
many many users confirm its correct behaviour in Real World code.

We have to separate the quality label of the library
from the quality label of its authors. Maybe that helps.

> Nobody really has a problem with the stability of shared_ptr, for
> example, and yet look at its list of breaking changes over the years:

Most of these were extensions, bugfixes or improvements,
not interface or silent breakage, right?

The counter example:
I had hard times with the rather silent change in spirit concerning
trailing whitespaces and enforcing end_p.
I agree with the change decision, but the change could have been
advertized in big red letters on the main web page.
It took me several months to detect _and_ understand the rather
subtle errors it generated and this prevented migration to a new version
of boost for a long time.

This is OK for me, since Joel saved me a lot of time, but yes,
this *change* broke all my code at once - silently. Something
I do not like at all.

The question is: can we work around this kind of problem easily?
I guess, no.

In another post you ask:

> So what happens to the iterators library when it's time
> for the rewrite I've been planning? I intend, as much as
> possible, to maintain compatibility with the old interfaces,
> of course. Is that still a "stable" library?

Considering the interface: no.
I'd prefer you advertise and introduce a new library as
replacement candidate for the old library and have
them both, the old and the new one, live together in boost
for at least one year before the switch and the deprecation
of the old one takes place. By this you have 2 things at a time:
Fast release process *and* satisfied customers.


P.S.: I am on my knees again: I managed to *use* iterator_adaptors
without understanding them at all. It works and I never had to
touch the code again for 3 years now. Thank You.
I now forgot everything I once read and learned about iterators.
Please don't change it ... please ...


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