Subject: Re: [boost] This AFIO review
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-08-23 02:18:10
On 8/22/15 2:39 PM, Hartmut Kaiser wrote:
>>I can tell you that I personally would not be comfortable sending
>>AFIO into the main Boost distribution until after Monad has been
>>reviewed here, so even if there is a universal unconditional
>>acceptance of AFIO by everyone here, I will personally guarantee I
>>won't send in a final AFIO until after Monad is reviewed here.
To put things in perspective, I might relate my experience along these
lines with the serialization library.
The serialization library is pretty large and complicated. Along the
way I needed a few items which weren't already in boost such as
Singleton, (still not in boost), a generalization of io_state_saver,
composible iterators to implement filtering (I called these "dataflow"
iterators, strong_typedef (now winding it's way through standard library
process as "opaque typedef", and others. I made versions of the
components and documented as if they were separate libraries and put
them in the Boost namespace. Documentation of these components can be
found within the documentation of the serialization library under the
section titled "Other Classes". My intention was to get the
serialization library working and accepted. Then at my leisure, I could
get them "promoted" into separate boost libraries. That never happened
as once the serialization library got accepted, I didn't have the energy
to promote them as separate libraries - and it didn't matter much anyway
as people do use them as if the were separate libraries. In only a
couple of cases have official boost libraries been added which replace
There was one bit of fallout from all this. I caught hell for putting
them in the boost namespace. So I moved then into the
boost::serialization namespace and that was pretty much the end of it.
In summary, these ancillary components were treated as implementation
detail by reviewers of the serialization library but were conceived,
packaged and documented as separate libraries. So they remain today.
So I don't see a huge problem that part of the implementation of AFIO is
packaged as an orthogonal component. It only has to be reviewed in so
far as the implementation of AFIO is reviewed.
Having said that, I did follow he discussion of Monad and was not
convinced it is suitable as a real library. No need to go in details here.
I saw a little bit of the discussion and attended Niall's presentation
on API Bind. As far as I can tell, this addresses the issue of library
API versioning. This is a subject we've never explicitly addressed and
is much bigger than one library. To make sense it really has to be
considered as more than just an implementation detail of the AFIO
library. But for now, the only way forward is to consider it as only an
implementation detail of the AFIO library which offers facilities for
library version control that other libraries don't offer. I think it was
a mistake for Niall to include this - it's going to be tough enough to
get AFIO over the bar without carrying any extra conceptual baggage. A
typical programmer problem - scope creep - I plead guilty.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk