Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-05-14 18:13:02

On 5/14/17 7:56 AM, Niall Douglas via Boost wrote:

> Apparently some years ago they were common enough in submitted new Boost
> libraries, and indeed some internal sublibraries went on to later become
> Boost libraries in their own right.
>
> We should proceed here with the Outcome review the same way as it was
> with those preceding cases. Whatever the precedent is.
>
> (I'm not sure what the exact precedent is, whomever knows for sure
> please speak, but be aware that most of the dependency on boost-lite is
> substitutable for Boost proper)

I can't say I know for sure, but I do have some experience with this.

While creating the serialization library, I depended on existing boost 
solutions to the extent possible.  MPL, config, spirit and I'm sure a 
bunch of others I don't remember. Someone else later added file_system 
and system to the tests. So there is, was and always will be a strong 
dependency between the serialization library and the rest of boost.

Still I needed some stuff that didn't exist: extended_type_info, 
composable dataflow iterators, BOOST_STRONG_TYPEDEF, singleton, 
state_saver, BOOST_STATIC_WARNING.  I created them as "private 
libraries" in order to keep the development effort within bounds. It's 
much easier to build and maintain a library as the composite of 10 
smaller otherwise decoupled components than try to understand things as 
a whole.  I also looked forward when some of these "private libraries" 
might get promoted to being boost libraries in their own right.  What 
actually happened was:

a) I tried to put these in boost namespace as they were not really part 
of the serialization library itself.  I caught hell for this from an 
important booster who is now no longer involved in boost.  So I moved 
them below the serialization namespace.

b) a number of these "private libraries" got adopted for general usage 
such that I get bug reports related to usage outside the serialization 
library.  These include dataflow iterators, strong typedef, and singleton.

c) a number just didn't work out - BOOST_STATIC_WARNING could never 
really be made to work across all platforms.  BOOST_STRONG_TYPEDEF fell 
out of use in the serialization library due to evolution in 
understanding on my part - but continues to be used.

d) a number got supplanted by real boost libraries - though I didn't 
update the serialization library to use them.  Type index is similar to 
extended type info.  We now have a component for dealing with unicode 
(which hasn't worked for me BTW). We now have boost.ranges which looks 
to me to replace dataflow iterators

One key component doesn't fit the above - boost::utf8_codecvt written by 
ron garcia many, many years ago.  He must have done a good job as it 
seems to be the only reliable implementation of this much needed 
facility.  This was one of the components I wanted to add to the boost 
root but was prohibited from doing so.  It was shared between several 
libraries so it wasn't a good idea to put it under serialization.  But 
being in boost detail there was no place for tests - which was pretty 
important since may standard libraries had quirky behavior in this area. 
While no one was looking, I snuck in a test somewhere which helped but 
we're still #including the source into other libraries because 
utf8_codecvt was never "officially reviewed".  This will be an ongoing 
saga since <codecvt> is now being dropped from the standard for being 
unreliable - oh well.

So that short story describes my experience in this area - I don't know 
if it explains anything though.  Make of it what you will.

Robert Ramey