Am 28.08.2015 4:29 vorm. schrieb "Niall Douglas"
:
On 27 Aug 2015 at 11:40, Thomas Heller wrote:
The idea is that no one ever need implement the Concurrency TS themselves ever again. Just pick up a copy of Boost.Monad/Outcome. Write your policy class for your custom variant. Profit.
Why not just call what it is? Future or FutureFactory or LightweightFuture?
I'm happy with all three of those names too. But I suspect anything which contains the word "Future" will bring even more attacks by people who have not looked at the design nor the code and just want any efforts by me killed off period. Hence I have avoided those names to date.
The reason why people, including me, are sceptical against is because we don't know what the added value will be. We asked you several times about performance results etc to proof your claims. Why should it be bad to have basic building blocks for asynchronous result transportation? This is of course something to strive for, as long as it brings clear advantages over what std implementations provide! Do you really think though it will be easier if you label your stuff with something that it clearly isn't?
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: