On 28 Aug 2015 at 22:30, Michael Caisse wrote:
There have been several suggestions (implicit and explicit) to move this type into the boost::afio namespace, but I haven' seen a response from you. Have I just missed it?
It's more that the suggestion is irrelevant with respect to the library. The code base as presented for review already exclusively uses boost::afio::monad<T>. It is only the just-added workshop tutorial which uses monad directly which made people think monad is not an internal library, and which I now realise was a mistake due to bad optics.
I'm afraid that AFIO isn't able to be reviewed because there are so many questions about other someday-to-be libraries in the boost namespace.
What are your thoughts?
I think many if not most other reviewers have not found the namespace layout nor dependent libraries an obstacle to making good reviews. I'll put it another way: the discussion to date has covered pretty much every thing I expected would be found of interest during a Boost review. This is why I felt AFIO was ready for review - the library had progressed to a point where I alone could go no further without a review. Even if rejected, these last nine days or so have been highly valuable. They have confirmed that my understanding of the tradeoffs in the design matches that of the community's. A big shock was how bad my documentation is, and how I really do need to go a lot slower in the tutorial than I have. My CppCon presentation should be much the better for this review and I am incorporating the name changes and feedback into the presentation materials. Renaming monad to outcome is literally a five minute job, as is rewriting how monad is bound into to code examples to `using BOOST_AFIO_V2_NAMESPACE::outcome`. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/