Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-08-23 18:46:00

Le 24/08/15 00:17, Niall Douglas a écrit :
> On 23 Aug 2015 at 23:57, 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.
>
>> BTW, the link to Boost.Monad [1] is broken in
>> https://boostgsoc13.github.io/boost.afio/doc/html/afio/overview.html.
> I profoundly apologise. In preparation for this review I relocated
> the Boost.Monad documentation onto GitHub's web service at
> https://ned14.github.io/boost.monad/ as it's more reliably there than
> ci.nedprod.com.
>
> I obviously forgot to update the link in the AFIO docs, despite
> having specifically moved the docs for this purpose. It's fixed now
> on develop branch. Thanks for the spot.
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.
>
>> Just a question, does the user need to use some APBind interfaces or is
>> this just an internal implementation detail (Sorry, I don't know nothing
>> about APBind)?
> If you want AFIO to use Boost.Thread, you define
> BOOST_AFIO_USE_BOOST_THREAD=1 before including. Else it uses the STL
> thread. The same goes for BOOST_AFIO_USE_BOOST_FILESYSTEM  and
> ASIO_STANDALONE.
>
> If you want to always use latest AFIO, you bind afio like this:
>
> namespace afio = boost::afio;
>
> 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?
>
> That's probably all most people care about. More advanced stuff can
> be seen at
> https://boostgsoc13.github.io/boost.afio/doc/html/afio/FAQ/multi_abi.h
> tml.
>
>> It will be easier to know the scope of the review and what is left for
>> the near future. Is the monad part of the review?
> I am happy to accept bug reports on monad<T>. But I don't think the
> AFIO review is reviewing monad<T>, nor do you need to.
If class monad is not included in AFIO, the documentation shouldn't use it.
>
> I mean, if you like the design of boost::shared_future<T>, then by
> definition you like the design of monad<T>. I would have said
> monad<T> is therefore uncontroversial, as it's already in
> Boost.Thread and is very well understood (especially by you
> Vicente!).
I've already post in this ML some of my concerns respect to this class.
>
> Just everywhere where you see monad<T>, replace it in your mind with
> boost::shared_future<T>. It has the same API and same behaviour.
>
>
I would prefer to don't need to do that. You say that monad is like a 
shared_future ready, so why don't you just replace the uses of monad by 
shared_future<T> in the documentation so we know of what we are talking of.

Sorry but I can not review a document that makes reference to things 
that are not yet adopted by Boost.

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.

Best,
Vicente