A Challenge Problem for Promise Designers (was: Re: Futures)

Claus Reinke 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 
for them. 

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 mailing list