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