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'.
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
