Promises

David Herman dherman at mozilla.com
Tue Nov 6 11:55:29 PST 2012


I agree that promises should be standardized in Ecma-262. There are a number of subtleties that'll need to be hashed out:

- the tension between the flexible structural ("duck") type and the desire to have the semantics do different things based on dynamically testing "whether" something is a promise:
  * the common practice (sadly not at all spelled out in Promises/A) of treating a resolved value that is a promise as continuing to defer resolution
  * the `when` operation that either calls its callback synchronously or asynchronously depending on whether it's a promise

- whether it's a bad idea (*cough* it is *cough*) for `when` to do that

- whether promises ever call their callbacks synchronously

- every single corner case of when an error is thrown and where it is thrown

- the interaction with the event-loop semantics, which needs to be specified in ES6 but isn't yet written

- whether the `then` property name should be a symbol or a string

- a way to create promises that don't expose their internal "resolve me" methods, etc. so they can be delivered to untrusted clients, e.g.:

    var [internalView, externalView] = Promise.makePair();
    "resolve" in internalView // true
    "resolve" in externalView // false

I agree this is worth doing, though definitely post-ES6. Personally I would like to work on it but for me anyway it has to take a back seat to modules and binary data.

Dave

On Nov 6, 2012, at 10:47 AM, David Bruant <bruant.d at gmail.com> wrote:

> Hi,
> 
> In a post to public-script-coord yesterday, Alex Russel wrote the following [1]:
> "[Web]IDL *is handy. *More to the point, it's the language of the specs we have now, and the default mode for writing new ones is "copy/paste some IDL from another spec that looks close to what I need and then hack away until it's close". This M.O. is exacerbated by the reality that most of the folks writing these specs are C++ hackers, not JS developers. For many, WebIDL becomes a safety blanket that keeps them from having to ever think about the operational JS semantics or be confronted with the mismatches."
> 
> I wasn't aware of this and then read through about a dozen WebAPIs [2] between yesterday and today and... discovered it's the case. In my opinion, one of the most absurd example is the DOMRequest thing which looks like:
> {
>   readonly attribute DOMString readyState; // "processing" or "done"
>   readonly attribute DOMError? error;
>   attribute EventListener      onsuccess;
>   attribute EventListener      onerror;
>   attribute readonly any?      result;
> };
> 
> Read it carefully and you'll realize this is actually a promise... but it has this absurd thing that it has to have both an error and result field while only one is actually field at any given point.
> Also, these APIs and JavaScript as it they are won't support promise chainability and the excellent error forwarding that comes with it off-the-shelf. Also, the lack of a built-in Q.all really doesn't promote good code when it comes to event synchronization.
> Oh yes, of course, you can always build a promise library on top of the current APIs, blablabla... and waste battery with these libraries [3].
> 
> I'm coming with the following plan:
> 1) get promises in ECMAScript
> 2) get WebIDL to support ECMAScript promises
> 3) get browser APIs to use WebIDL promises
> 
> About the first step, there is a strawman [4] that contains promises and it requires to define the event loop, so that's probably too much for ES6. Yet, it doesn't prevent to agree on a promise API that will be adopted in ES7.
> Besides the strawman, promises have run a long way from CommonJS [5] to jQuery [6] to Q [7] to Irakli's excellent post [8] to Domenic's recent rant [9] and I've missed a lot of other examples probably. The JS community is ready for promises. The idea has been used a lot.
> Different libraries have different APIs and I have no preference. The only things I really care about is chaining (with error forwarding) and a promise-joining function à la Q.all. I'll let people who care about naming fight.
> 
> I'm sure TC39 can come to an agreement *before* ES7 standardization, agreement that can be used by WebIDL and browser APIs (why not implemented long before ES7 work has even started).
> If you're a JS dev and care about promises, please show some support to this proposal :-)
> 
> David
> 
> [1] http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0122.html
> [2] https://wiki.mozilla.org/WebAPI#APIs
> [3] http://assets.en.oreilly.com/1/event/79/Who%20Killed%20My%20Battery_%20Analyzing%20Mobile%20Browser%20Energy%20Consumption%20Presentation.pdf
> [4] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
> [5] http://wiki.commonjs.org/wiki/Promises
> [6] http://api.jquery.com/category/deferred-object/
> [7] https://github.com/kriskowal/q
> [8] http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html
> [9] https://gist.github.com/3889970
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list