A Challenge Problem for Promise Designers
bruant.d at gmail.com
Fri Apr 26 06:36:57 PDT 2013
Le 26/04/2013 14:54, Kevin Smith a écrit :
> What exactly is the controversy here?
> I think we all agree with the semantics of "then" as specified in
> Promises/A+. (If not, then we have a really big problem!)
> If so, then the only real controversy is whether or not the API allows
> one to create a promise whose eventual value is itself a promise. Q
> does not: it provides only "resolve" and "reject". DOM Futures do by
> way of "Future.accept". As far as I know, there's nothing about Q's
> implementation that would make such a function impossible, it just
> does not provide one.
I believe at this point the question isn't so much "can I build a
promise for a promise?", but rather "what should be the default Future
// is y a Future?
I'm arguing in favor of y being guaranteed to be a non-Future value. It
is my understanding others would want y to be a Future.
That would be the controversy as I understand it.
More information about the es-discuss