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: