Re: [boost] This AFIO review - a modest proposal

Subject: Re: [boost] This AFIO review - a modest proposal
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-24 17:24:59

On 24 Aug 2015 at 11:52, Glen Fernandes wrote:

> Niall Douglas wrote:
> > And I have no problem if AFIO never enters Boost. I would think it a 
> > shame and a wasted opportunity as it solves a ton of pain points for 
> > those with such needs
> 
> Whatever happened to...
> 
>     > Niall Douglas wrote:
>     > > Firstly, you don't invest the multi-year effort to get a library
> into 
>     > > Boost because it's superior, as it probably isn't.  You do it
> because
>     > > of what you will become after you succeed: a Boost library author
>     > > who has passed the judgement of his or her peers. 

Remember I have more than one Boost library coming :)

AFIO will be the hardest to get in because it's so niche, and I've 
known that since the beginning. Monad will be hard to get in because 
it's too fundamental and everyone will have their own opinion and 
think they know better despite not having written one themselves, so 
we won't reach consensus. It'll just descend into argument.

My final planned Boost library before I move on from Boost to warmer 
climes is a reliable (a)synchronous transactional key-value store 
implemented using AFIO and Monad. That will get into Boost without 
issue because *everybody* needs to persist state especially on 
unreliable hardware. That will be the only unequivocably useful 
library I propose for Boost which very little argument can be made 
against, and I expect it will be unconditionally accepted. Once it's 
in, it also becomes much harder to reject AFIO and Monad.

> On a more serious note:
> > Totally separate to the async file i/o is the race free filesystem 
> > stuff. I would like to believe that people understand why a race free 
> > filesystem API is important.
> 
> Your documentation would be the best vehicle to convey (and prove) this. It
> doesn't do it for me right now. I may be the 0.0001% who doesn't need AFIO
> as you've currently designed it but ideally the documentation should help me
> understand why.

Ideally yes. But it's like writing long essays on why choose future 
over async_result.

About 20% find it very useful and approve.

About 20% think it clutter, confusing and annoying because it's just 
noise to them. You've seen people already say the AFIO documentation 
goes into too much detail about things you don't need to know.

The remaining 60% don't care, and that suggests it has a poor cost 
benefit when I could do other much more valuable things with the same 
time than write essays on stuff more than half of people are 
indifferent about.

In the end you're trapped. I take the view you don't ask uBLAS to 
explain from first principles matrix mathematics in its 
documentation. Why therefore ask the same of AFIO regarding file 
system theory?

Niall

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