Re: [boost] [outcome] non-interface-related concerns

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-27 16:43:47

>> I still hold open the offer of a fully Boost flavoured edition of
>> Outcome. I think it a mistake personally, but the offer is there. I've
>> given up on trying to instil awareness of the end user experience of
>> Boost into people on boost-dev.
> 
> I think your solution to dual boost/standalone version is all backwards.
> 
> An alternative is to have the Boost.Outcome as the main repository. This
> uses Boost.Config and possibly other accepted Boost libraries, and hides
> implementation details in boost::outcome::detail. No dependency on
> "boost-lite".
> 
> The standalone repository includes Boost.Outcome as a submodule. It also
> contains your substitutes for Boost.Config etc. (i.e. "boost-lite"), as
> well as CMake scripts.

I can see why you might think that organisation superior, and I did
start out with that design. In fact, boost-lite used to define the exact
same macros as Boost, precisely because of that organisation, the idea
was that boost-lite was a substitute for Boost.

But I inverted it after a bit of trial, so now boost-lite is an internal
implementation detail. The problem is that putting the common stuff on
the outside with a git submodule SHA stamp for the libraries makes your
developer workflow quite painful as everything must be kept in lockstep.
All my libraries are specifically designed to work alongside different
versions of themselves, so there is absolutely no problem if say AFIO v2
uses one version of Outcome, whilst another library uses a different
version of Outcome. And that lets you avoid having to keep everything up
to date all the time.

Indeed, for a long while there, AFIO would not compile with latest
Outcome for something approaching six months, but it didn't matter
because AFIO was SHA pinned to an Outcome and boost-lite which *did* work.

Does this make sense?

BTW, the name boost-lite is not long for this world as it has changed
its purpose and role. I am still thinking of a new name more suitable
for what it now is: a set of highly reusable utilities common between
all my libraries.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/