- 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