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/