I guess now is a good a time as any to pre-announce Promises/A+: https://github.com/promises-aplus/promises-spec
It’s an attempt to improve significantly on the minimal-but-perhaps-too-minimal Promises/A of CommonJS, making the language more rigorous and speccing several important things Promises/A missed. Here’s a short summary of the differences: https://github.com/promises-aplus/promises-spec/issues/17 The two most important ones, in my opinion, are: * Cover the case of handlers returning a promise (chaining) * Require asynchronous resolution Promises/A+ is a collaborative effort led by Brian Cavalier (when.js) with help from myself and Kris Kowal (Q), as well as Yehuda Katz (rsvp.js, TC39) and others with whom I am less personally familiar with but have also been very helpful. --- I say “pre-announce” because there are a number of bookkeeping issues we want to take care of before saying it’s truly done: https://github.com/promises-aplus/promises-spec/issues But everything important is already in the repo. We also have a (again, preliminary) conformance test suite at https://github.com/promises-aplus/promises-tests --- I hope this is helpful to TC39 or others considering promise standardization. My ideal vision is that the community experiments with promises + generators (a la taskjs) in the ES6 timeframe, then in ES7 we standardize on something like the concurrency strawman or a C#-like async/await pattern based on promises. We welcome feedback from TC39 and others, preferably as GitHub issues in the repo (and thus we can avoid derailing this thread). We’d especially love the eyes of spec-experienced folks such as those that frequent this list. From: David Bruant Sent: November 6, 2012 13:47 To: EcmaScript Subject: Promises 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
