W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Future feedback

From: Sean Hogan <shogun70@westnet.com.au>
Date: Wed, 08 May 2013 11:27:48 +1000
Message-ID: <5189AA14.7080205@westnet.com.au>
To: public-script-coord@w3.org
I have been considering the DOM Future proposal, including writing a 
rough implementation for browsers. Feedback:

1. The current proposal is reasonably straight-forward to implement in 
browsers (except for 'catch' in older browsers).

Of course, the motivation for a DOM Future standard is that DOM methods 
can return Futures. Polyfilling those methods may not be as 
straight-forward.


2. My implementation (and probably most of the Future-like libs) 
requires two unexposed browser features which must be emulated:

a. Queueing a task - that is, asynchronously executing a function
b. Isolating a task - that is, synchronously executing a function in 
such a way that errors are detected but not prevented from going to the 
console

If DOM Future was available they could almost be emulated with:

a. Future.accept().done(task);
b. new Future(function(r) { task(); r.accept(); });

but personally these features would be valuable even if DOM Future is 
never implemented.


3. The `catch` method throws an "Unexpected identifier" error in older 
browsers, including IE6-IE8.
I don't see the point of excluding these browsers from using a Future 
polyfill.
I also think that "catch" is a bad name because it implies a promise 
that Future can't deliver - that is, that all errors are caught.

I saw one library provided `fail` as an alternative to `catch`.

4. The current proposal requires Future to catch errors in all sorts of 
places:
- if `init` threw an exception
- if invoking `callback` threw an exception
- if calling the |`[[Get]]`| internal method threw an exception

This could easily give the impression that Future catches all errors, 
but it is trivial for an error to occur that permanently stalls the 
Future, for example

var o = {};
new Future(function(r) {
     setTimeout(function() {
         var result = o.run(); // an error that won't be caught
         r.accept(result);
     }, 100);
});

I think it is a mistake that Future automatically catches some errors - 
if I have to manually detect errors in one part of my code then just 
make me do it everywhere.

Personally I don't ever want unexpected errors to be caught - fail 
noisily - so I would rather that Future doesn't catch errors 
automatically. This is especially the case for external code that 
interfaces to mine - if the error is in their code I definitely want it 
to go to the console, whether or not my code can recover.


5. I also think it is a mistake for the resolver calls (accept / reject 
/ resolve) to fail silently when a Future has already been resolved. 
These things usually indicate an error in the logic of the code and the 
current spec is encouraging them as a coding practice.


6. I can't work out why a Future wouldn't provide (read-only) access to 
`state` and `result`. If they were present in the API I can't imagine 
anyone asking for them to be removed.


7. The `done` method definitions seem to have a couple of typos.
In one place it returns `void`, in another it returns a new Future. I 
believe it is supposed to return the context Future so that `done` can 
be chained.
Received on Wednesday, 8 May 2013 01:28:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC