Subject: Re: [boost] Monad
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-08-28 02:51:49
Am 28.08.2015 4:29 vorm. schrieb "Niall Douglas" <s_sourceforge_at_[hidden]
> 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
> 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?
> ned Productions Limited Consulting
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk