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

Claus Reinke claus.reinke at talk21.com
Thu Apr 25 09:37:36 PDT 2013

> I think we see a correlation -- not a 1.0 correlation, but something. Those
> who've actually used promise libraries with this flattening property find
> it pleasant. Those who come from either a statically typed or monadic
> perspective, or have had no experience with flattening promises, generally
> think they shouldn't flatten. 

I think the dispute could be settled easily: 

- flattening 'then' is a convenience
- non-flattening 'then' is necessary for promises being thenables
    (in the monad-inspired JS patterns sense)

Why not have both? Non-flattening 'then' for generic thenable
coding, and a convenience method 'then_' for 'then'+flattening.

That way, coders can document whether they expect convenience
or standard thenable behavior. And we can have convenience for
Promise coding without ruining Promises for more general thenable 
coding patterns.


More information about the es-discuss mailing list