Re: [boost] This AFIO review

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 
their functionality.

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.

Robert Ramey