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-28 11:29:20

On 28/05/2017 00:04, Robert Ramey via Boost wrote:
> On 5/27/17 3:03 PM, Niall Douglas via Boost wrote:
>>>> Some Boost developers are ideologically and irrationally attached to
>>>> "how things are done around here", yes.
> 
> Boost developers are attached to the current way of doing things.  But
> it's not irrational.
> 
> Boost libraries are source code.  The do not (or should not) depend on
> build tools, the particular compiler, the operating system or whatever.
> They might depend on other source code libraries - boost or std.
> 
> There is a wide combination of build environments which can incorporate
> this source code. If they follow C++ rules the boost source code can be
> incorporated into the build.
> 
> Now it looks like you've injected a dependency going in the other
> direction - that the usage of outcome is dependent upon CMake, Git, Git
> submodules. 

I have repeated myself several times now on this. End users can include
the outcome header and get to work. No cmake, git, or anything else.

> Note that this is dependent upon the original dependencies
> of outcome on other boost libraries.  The fact that these dependencies
> are masked by pre-processing just hides this fact.  In boost, if an
> error is detected in config.hpp (for example) any other module which
> depends upon it needs to be re-built this can be done locally if
> desired. That's all.  In your world the the preprocessing has to be
> redone so the user then rebuilt. So the "user" will need the original
> config.hpp anyway.

I agreed well into last week to replace the extensive preprocessor
metaprogramming with a template based solution. I don't see why people
are still going on about this. I heard that people don't like the
preprocessor work. I agreed to replace it. It's no longer a thing.

> Of course this applies to boost module which has been "imported" into
> outcome.  If outcome has made it's own substitutes from scratch - like
> in the case of config.hpp - the situation is worse, the maintainer will
> have to maintain something that is repeated in boost.  More work to do.
> Since we've now coupled the two tasks in both directions, they have to
> be handled as a pair.  If other libraries were to adopt this approach it
> would be maintenance nightmare.  Just the fact that that it depends on
> bunch of convoluted (git and submodules) and flakey (CMake) tools should
> be a tip off.
> 
> I could go on but it's clear I'm not going to convince you this is a bad
> idea.  I get that.
> 
> But your major blunder is to try to tail gate a whole new way of doing
> things which was bound to be controversial into boost by attaching to an
> otherwise simple and perhaps useful facility.  It's a pity since with a
> different approach you might have gotten more credibility and success.
> Your idea of addressing the issue of distributing minimal subset of
> boost related to a particular library (or set of libraries) doesn't
> belong here. It's unrelated to outcome, it's a boost-wide issue - not an
> issue with outcome. By conflating these issues and coupling it with your
> code you've made it almost impossible to get any useful part of the
> library accepted.
> 
> And it's not because boost developers are ignorant of modern C++. That's
> just wishful thinking on your part.  It's on you because you bad decisions.

Well, an ad hominem attack had to happen at some point.

Let me firstly defend boost-lite, or rather the common support code
currently called boost-lite but will be renamed at some point. It is
quite frankly an amazing solution to the common framework and support
needs of C++ 14 libraries. It lets new library authors get up and
running with a new library very quickly, implementing best current
practice build, packaging, test, dashboarding, version management and
lots more without library developers having to think about any of that.
It is free of legacy baggage, and saves me on a daily basis a ton load
of time and hassle even amongst the three of my libraries it is used in.
It also can scale out to an arbitrarily high number of libraries in a
decentralised collection, far more incidentally than Boost could ever
dream of precisely because of its decentralised design. I am proud of
its design, the fact it confounds so many experts who study how it works
is testament to the breath of fresh air it bring to modern C++ library
design. I don't claim it to be perfect, it suffers particularly from
immaturity, and hence I don't recommend that anyone else use it yet. But
rather than attack it because it's different, you really should study it
and learn from it because it has a lot of really great ideas and
implementation in there. It could become the base of a major leap
forward in standards aspiring C++ 14 and C++ 17 libraries precisely
because we can finally dispense with the whole "one code silo to rule
them all" philosophy.

But let's return now to Outcome, as that's what this review is about.
What happens if Outcome is accepted into Boost in a non-Boost flavoured
form, as indeed it has been presented for review? I have already covered
this in this review before, but let me repeat one solution of many possible:

1. boost-lite is an excellent neighbour to all other C++ libraries,
including different versions of itself. It is benign to include into any
translation unit under any circumstances.

2. As Outcome was accepted in std-flavoured form, I would eliminate the
namespace bind technology from boost-lite to allow switching between the
C++ 11 STL and the Boost STL. I would have deleted it last year except
that I wasn't sure if you guys would demand a Boost flavoured library or
not.

3. If the Boost release and package managers felt that git sub-submodule
support was not going to be allowed, I would use __has_include (which
works on all the compilers Outcome works on) to have Outcome probe for a
checked out internal edition of the boost-lite git submodule. If not
found, it would fall back to Boost.Config, Boost.Stacktrace etc for
those parts, and rely on a local copy of some boost-lite support files
for the rest.

4. I now have a single git repo which works well standalone and within
Boost. I am happy, Boost is happy, Boost users are happy. Let's all
dance. As I have said repeatedly during this week, these are all
packaging and process problems. They are inconsequential to acceptance
or rejection of this library. I am sorry you don't see it that way
Robert, but quite frankly, your opinion has no technical basis in fact.

Niall

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