Sorry for ignoring the rest of this thread in my first reply, but I'll try
to cover as much ground as I can here. Response inline:
On Tue, Nov 6, 2012 at 6:47 PM, 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.
>
There are absurdities like this all over DOM for want of promises. A short
list must include:
- XHR's "readystate" system
- geolocation APIs
- window.onload, DOMContentLoaded, etc.
- CSS OM measurement APIs.
I'm sure I'm missing some. I'm also aware of new APIs that could be re-cast
in terms of Promises/Futures/whatevs to good effect.
> 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
>
>From a "doability" perspective, I think this is backwards. Browser vendors
are more likely to add ad-hoc APIs, and the large problem of DOM design is
that Promises aren't in the WebIDL "toolchest". Further, this group is even
more gunshy than many W3C WGs to make progress in important areas for fear
of backwards compatibility burdens. It's also harder to iterate ES since it
moves so slowly (in relative spec-org terms; all spec processes move slowly
in human terms).
My plan, as a result, inverts yours:
1. Get "DOMPromises" done in order to fix some busted proposed API. My
current hope is WebCrypto who can both avoid a design catastrophe and
introduce a new, widely implemented API on a relatively short timeframe
2. Once we have DOMPromises implemented, we advocate broader
use throughout DOM APIs.
3. Introduce ES7 Promises as a compatible subset of DOMPromises
In an ideal world we'd go your route (as we would have with
Object.observe() vs. Mutation Observers), but TC39 isn't known for adding
API quickly, no matter how popular or well-argued the case.
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 :-)
>
I support getting Promises done where they'll make an impact and right now
DOM is the squeeky wheel. Yes, we need them in JS, but getting the eyes
around this particular table opened to that is a fight I don't want right
now (as the rest of this thread is painful, painful proof).
> [1] http://lists.w3.org/Archives/**Public/public-script-coord/**
> 2012OctDec/0122.html<http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0122.html>
> [2]
> https://wiki.mozilla.org/**WebAPI#APIs<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<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<http://wiki.ecmascript.org/doku.php?id=strawman:concurrency>
> [5]
> http://wiki.commonjs.org/wiki/**Promises<http://wiki.commonjs.org/wiki/Promises>
> [6]
> http://api.jquery.com/**category/deferred-object/<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<http://jeditoolkit.com/2012/04/26/code-logic-not-mechanics.html>
> [9] https://gist.github.com/**3889970 <https://gist.github.com/3889970>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
