Re: [boost] This AFIO review

Subject: Re: [boost] This AFIO review
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-08-23 09:54:07

Robert,

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

Your insights are very much appreciated and I fully agree with your
assessment. We have had similar situations with Spirit. This however is not
my point. I have no problems with sub-libraries being created/used as part
of the implementation of a Boost library. My concern is related to the fact
that AFIO is apparently not ready for review: it is under heavy development
still, constant changes and postponements show that; even the author says
that he knows of 'at least half a dozen' issues he needs to fix; the library
is known to have inadequate performance (the author's own words!); not even
the public API has settled (the author mentioned it may change if some other
libraries are accepted); etc. 

All of this makes the impression of rushing a not-quite-ready (possibly very
useful) library into Boost just for the sake of it.

Why do we even review a library which is not ready yet? Isn't that a huge
waste of everybody's valuable family time? 
Could I get some answers from the review manager, please?

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu