Boost logo

Boost :

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-08-24 05:52:37


On 24.08.2015 12:27, Andrey Semashev wrote:
> On 24.08.2015 04:29, Niall Douglas wrote:
>> On 24 Aug 2015 at 0:46, Vicente J. Botet Escriba wrote:
>>
>>>>> I believe that I need something more about monad<T> than what I have
>>>>> found in the documentation.
>>>> If there is anything missing, please do say in detail.
>>>>
>>> Is this link part of the review? I don't believe, so could you point me
>>> where the monad class is documented in AFIO? If it is not documented,
>>> why it is used so broadly.
>>
>> It is used in the tutorial because as we progress through each stage
>> of increasing complexity, you can see that the data_store class
>> member functions lookup() and write() have either a monad<T> or a
>> shared_future<T> return type depending on whether the API is
>> synchronous (monad<T>) or asynchronous (shared_future<T>).
>>
>> I was trying to keep the interface class for each stage as identical
>> as possible, so monad<T> was a natural fit to make the STL iostreams
>> example look exactly like the AFIO asynchronous example. I suppose
>> what you're saying here is that the tutorial should not be using
>> monad<T> because monad<T> is not documented in AFIO.
>>
>> I can easily rewrite the tutorial code to not use monad<T>, it's no
>> problem.
>>
>>>> If you want to pin a specific ABI which won't break in the future,
>>>> you bind afio like this:
>>>>
>>>> namespace afio = BOOST_AFIO_V2_NAMESPACE;
>>>
>>> Where can I find the description of this macro on the reference
>>> documentation?
>>
>> https://boostgsoc13.github.io/boost.afio/doc/html/afio/quickstart/workshop/naive.html
>>
>>
>>> We have two options:
>>> * we wait to review AFIO once Monad is reviewed in Boost
>>> * You include in AFIO, whatever you consider is need from Monad and only
>>> then we review AFIO.
>>
>> I can remove monad<T> from all the tutorial code. Or I can include
>> documentation of monad<T> in AFIO. Which would you prefer?
>
> Niall, I think you're missing the point. Is monad<T> part of the library
> interface? I.e. is the user allowed to use it to work with the library?
> If the answer is yes then it's a public part of the library and should
> be documented and reviewed. It doesn't matter if it is possible to code
> around it. If the answer is no then why is it there in the first place?

Having looked at the docs, I see:

The monad<> comes from Boost.Monad which is a dependency of Boost.AFIO.

To me this looks like Boost.AFIO uses a not yet accepted library in the
interface. In this case I would say Boost.Monad should be reviewed first
and Boost.AFIO review should be postponed until after Boost.Monad is
reviewed and _accepted_.

Alternatively, Boost.AFIO could be reimplemented to exclude the
dependency on Boost.Monad; this would include removing its mentioning in
the docs. But I don't know enough of Boost.AFIO or Boost.Monad to say if
this would be an improvement of Boost.AFIO.


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