On 29 Aug 2015 at 9:21, 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 think you may have missed parts of reviews. A few influential reviewers [1] have indicated that having components such as Monad and APBind is a non-starter for a review or an immediate "no" vote (Vicente [2] and Robert are just two on the user list... others on the dev list).
You have put a great deal of effort into this library and I would like to see the chances of acceptance during the review not hindered by non-essential choices. The bottom line is that implementations in the boost::afio namespace will have different scrutiny than automatic promotion to the boost namespace. Start with these concepts in the boost::afio namespace and then at a later date, request a review to promote them to the boost namespace as full-fledged libraries.
I appreciate all of what you just said. But please listen to what I just said: AFIO's use of these two dependent libraries is entirely internal in the implementation and header code. Where I came unstuck is that the documentation treats those two libraries as if there are not internal implementation libraries, and the documentation both refers to them by name e.g. Boost.Monad, Boost.APIBind and the code examples use them directly instead of via their boost::afio::* mapping. This makes them appear far more important than they are to the end users of the presented library.
I don't think it is worth risking the review outcome on trying to get multiple libraries into the boost namespace.
I think that most reviewers, once they actually looked at the code, realised that the use of Boost.Monad and Boost.APIBind is a purely presentational issue caused by a bad choice in the documentation. As I have said on many occasions now, I realise that was a mistake, but as I cannot change what has been presented for review I am stuck with it. For the record, I estimate that all mention of APIBind and Monad can be completely eliminated from the AFIO documentation and externally facing API in about two days of work. They are totally incidental to AFIO the library presented here for review. This is why I said I would be upset with reviewers who refuse point blank to review this library purely on a documentation mistake if they then later on find severe design flaws in the library after I have invested an additional 500 hours in the lightweight futures refactor based on the presented API and design (which is my current estimate, and I am usually within 10% of my estimates when estimating on my own code). I think anyone would react similarly. However after the many threads of discussion this week regarding the design tradeoffs in the AFIO API and design, I am confident that in any future review (if needed) that nothing not discovered in this review will come up. In this regard this review has been highly successful, and very valuable, irrespective of eventual outcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/