Promise.cast and Promise.resolve
raynos2 at gmail.com
Tue Jan 28 21:08:43 PST 2014
> But, I would pick one or the other over one with multiple personalities
This is a good mentality to have. Consider picking the one that allows the
other one to be implemented in user land.
This would allow both parties to benefit from the integrated tooling &
performance boosts of it being a native primitive. i.e. everybody wins.
On Tue, Jan 28, 2014 at 8:12 PM, Kris Kowal <kris.kowal at cixar.com> wrote:
> In this case, a half pursuit of type purity is a side quest at the expense
> of users. Having two ways to resolve and two ways to observe a promise is
> unnecessarily confusing. In my experience, one method like "then", that
> unwraps recursively, and one function, like "Promise.cast", that
> automatically lifts if necessary, and "then" handlers that return into the
> waiting hands of "Promise.cast" are coherent and ergonomic. Having a choice
> between "cast" and "resolve" and a choice between "then" and "chain", will
> leave developers unnecessarily confused and worried all the while they use
> or abandon Promises as too subtle.
> For quite some time, grammarians have been losing a war to impose Latin
> purity on English, in the case of split infinitives. Not long ago, the
> famous phrase, "to boldly go", were a racy departure from convention
> because in Latin, the infinitive verb "to go", is a single word, and you
> simply would not break the word in half to put a poetic adverb between the
> Auto-lifting/unwrapping promises are beautiful. Purely monadic promises
> are beautifully captured by type theory. But, I would pick one or the other
> over one with multiple personalities. I would pick "Promise.cast" and
> "then", let complexity melt off the spec, and stop worrying.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss