A Challenge Problem for Promise Designers (was: Re: Futures)
claus.reinke at talk21.com
Fri Apr 26 01:40:07 PDT 2013
> A Future for a Future seems like a corner case compared to the
> broader simplicity of an implicit unwrap.
The argument is not about whether Future<Future<...>> is a common
case. The Argument is that Future<...> and Array<...> and Optional<...>
and things that may raise catchable errors and other types have enough
structure in common that it makes sense to write common library code
One example is a map method, other examples may need more structure -
eg, filter would need a way to represent empty structures, so not all
wrapper types can support filter.
The goal is to have types/classes with common structure implement
common interfaces that represent their commonalities. On top of those
common interfaces, each type/class will have functionality that is not
shared with all others. As long as the common and non-common
interfaces are clearly separated, that is not a problem.
It is only when non-common functionality is mixed into what could
be common interface methods, for convenience in the non-common
case, that a type/class loses the ability to participate in code written
to the common interface. That is why recursive flattening and implicit
lifting of Promises is okay, as long as it isn't mixed into 'then'.
More information about the es-discuss