Boost logo

Boost :

Subject: Re: [boost] This AFIO review - a modest proposal
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2015-08-24 08:49:59


Niall Douglas wrote:
> Glen Fernandes wrote:
> > Isn't "I don't understand the point of this library" a valid reason
> > for rejection?
>
> In itself, no I don't think so. There are at least ten libraries in Boost
> I have no understanding of the point of

If almost nobody the understands point of a proposed library to the extent
that almost nobody recommend its acceptance: I would think that it isn't
unjustly rejected. I believe niche use case libraries have a place in Boost.
I suspect, though, that an asynchronous file I/O library falls into the
category of something that most people want in Boost.

I haven't figured out entirely where the disconnect is. It seems like you're
saying "This is the async file I/O library that you need; not the async file
I/O library that you want." You also say that only a tiny fraction of
developers have those needs. Are any of them going to be reviewing this
library?

> Can you explain what is not straightforward more precisely please?

Sure. With regards to the examples:
- Be more concise,
- Have less standard out statements,
- Have less comments,
- Have no conditional compilation
  * BOOST_AFIO_USE_LEGACY_FILESYSTEM_SEMANTICS? How can parts of AFIO be
legacy?
  * #if 0? In an example?
  * No platform specifics

The other advice I have is that you may want to omit a comment like "This
section was not finished in time for the beginning of the Boost peer review
due a hard drive failure induced by the testing of AFIO-based key-value
stores in this workshop tutorial (sigh!)" in the documentation. You don't
want prospective reviewers to wonder if they should back up their hard drive
before trying AFIO. :-)

Glen

--
View this message in context: http://boost.2283326.n4.nabble.com/afio-AFIO-review-postponed-till-Monday-tp4678123p4679161.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk