- From: Marcos Caceres <w3c@marcosc.com>
- Date: Sun, 17 Feb 2013 15:06:26 +0000
- To: Miko Nieminen <miko.nieminen@iki.fi>
- Cc: Shwetank Dixit <shwetankd@opera.com>, www-tag@w3.org
On Sunday, 17 February 2013 at 14:39, Miko Nieminen wrote: > I quite don't see how to simplify IDB syntax much more. [1] shows how it can be written using promises. As Jonas Sicking, who is the Editor of the IDB spec, states: "As you can see, the .then function on DOMFuture/Promises certainly makes the code cleaner and removes a lot of the syntax overhead. But the capabilities are exactly the same." http://lists.w3.org/Archives/Public/public-sysapps/2013Feb/0070.html Relating to DOMRequest, David Braunt writes: "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]. " https://mail.mozilla.org/pipermail/es-discuss/2012-November/026188.html So it appears there are ways to simplify the code. Getting rid of some of the error/result absurdity would be helpful. -- Marcos Caceres http://datadriven.com.au
Received on Sunday, 17 February 2013 15:06:58 UTC