Le 29/06/15 19:03, Niall Douglas a écrit :
On 29 Jun 2015 at 17:54, Vicente J. Botet Escriba wrote:
Niall, I don't see why do you need to define a concrete monad class that is used to define other monadic types. The implementation of each specific monadic type has its own trade-offs.
We can provide monadic operations for optional/expected/future/....
Why do you need to have a concrete monad class? What is the added value? Let me flip the question to you.
Why does it matter how the monadic types are implemented? All the user needs to care about is that monad<T>, result<T>, option<T>, future<T>, future_result<T> and future_option<T> behave according to strict and sensible rules which make sense to program against. If it is an implementation detail it is no worth continuing the discussion at the design level. Could we then avoid to mention the monad class on these threads as it is an implementation detail. So what are the public classes you would present for review?
Vicente