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 <bruan...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
