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.
On Nov 6, 2012, at 10:47 AM, David Bruant <bruant.d at gmail.com> wrote:
> In a post to public-script-coord yesterday, Alex Russel wrote the following :
> "[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  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.
> Oh yes, of course, you can always build a promise library on top of the current APIs, blablabla... and waste battery with these libraries .
> 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  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  to jQuery  to Q  to Irakli's excellent post  to Domenic's recent rant  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 :-)
>  http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0122.html
>  https://wiki.mozilla.org/WebAPI#APIs
>  http://assets.en.oreilly.com/1/event/79/Who%20Killed%20My%20Battery_%20Analyzing%20Mobile%20Browser%20Energy%20Consumption%20Presentation.pdf
>  http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
>  http://wiki.commonjs.org/wiki/Promises
>  http://api.jquery.com/category/deferred-object/
>  https://github.com/kriskowal/q
>  http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html
>  https://gist.github.com/3889970
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss