On Wed, Nov 14, 2012 at 11:25 AM, Domenic Denicola <
[email protected]> wrote:
> Why go purposefully against the existing terminology of the JavaScript
> ecosystem? Just say “deferred” where you have “promise” and “promise” where
> you have “future” and you avoid needless confusion and conflict.
>
It's true that the terminology exists in JS, but it's been identified that
these terms may have been misappropriated. Kevin's proposal is easier to
reason about:
"Promise to deliver a value in the Future"
vs.
"Defer the delivery of a value, and that's a Promise"
...awkward? Note that I disagree with jQuery's use of the terminology,
which matches the latter.
> This isn’t Scala; we have existing terminology for exactly these concepts.
> Just use it.
>
I'd be interested in seeing usership data for libraries using this existing
terminology.
Rick
> *From:* Kevin Smith
> *Sent:* November 14, 2012 11:23
> *To:* David Bruant
> *CC:* Mark S. Miller, EcmaScript
> *Subject:* Re: Promises
>
>
> If the second argument is optional, it's possible to have both one-arg
>> and two-arg styles in the same API.
>> What do people think about this idea?
>>
>
> Maybe - minimalism served the class proposal quite well. It might be a
> good strategy here, too.
>
> Here's what I'm thinking:
>
> // Creates a new promise
> let promise = new Promise();
>
> // Resolves the promise (ala Q)
> promise.resolve(value);
>
> // Rejects the promise (ala Q)
> promise.reject(value);
>
> // A handle to the eventual value of the promise
> promise.future;
>
> // The then method (ala Promises/A+)
> promise.future.then(val => {
>
> // Success handler
>
> }, err => {
>
> // Error handler
> });
>
> // Returns a future for the value
> Promise.when(value);
>
> // Returns a rejected future with the specified error
> Promise.reject(error);
>
> // Returns a future for every eventual value in the list
> Promise.whenAll(list);
>
> // Returns a future for the first resolved future in the list
> Promise.whenAny(list);
>
> Initial implementation here: https://github.com/jscloud/Promise
>
> I think it's important to separate "Promise" from "Future". Back in the
> CommonJS mailing list days, there was contention between Promises/A
> (thenables) and Promises/B (basically Q). But they really are
> complementary: futures and promises.
>
> - Kevin
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
