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

Re: Future feedback

From: Sean Hogan <shogun70@westnet.com.au>
Date: Tue, 14 May 2013 13:12:28 +1000
Message-ID: <5191AB9C.3010403@westnet.com.au>
To: David Bruant <bruant.d@gmail.com>
CC: public-script-coord@w3.org
Hi David,

Thanks for the links. I tried to read all the Future related comments on 
this mailing list and the W3 DOM list and didn't see these issues 
raised, though I thought it likely they were items of discussion somewhere.

My responses are inline.


On 11/05/13 5:02 AM, David Bruant wrote:
> Hi Sean,
>
> Answering to the part I have an answer to.
>
> Le 08/05/2013 02:27, Sean Hogan a écrit :
>> 3. The `catch` method throws an "Unexpected identifier" error in 
>> older browsers, including IE6-IE8.
> ['catch'] is the answer for the time older browser matters (which 
> depends on people's requirements) [1]
>
>> I saw one library provided `fail` as an alternative to `catch`.
> This been discussed early [2]. I prefer "fail" too, but don't care 
> that much as long as there is something.
>


Those discussions don't address the fact that `catch` is also a 
misleading name.


>> 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.
> For context, see [3].
>


Fair enough.


>> 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.


I see that the inconsistency in the spec has been fixed. I assumed 
chaining would be allowed since

     future.done().done()

would be the same as

     future.done(); future.done()

I am neither for nor against chaining `done` - it is a non-issue anyway.


> The purpose of done is to avoid a to chain so that uncaught errors 
> aren't propagated without being caught. When you call .done and the 
> last promise had an error, the devtools can tell you so (telling you 
> before .done could be confusing as the error might be later caught)
>


`.done()` **does not** provide a guarantee against silent failure. It 
**allows** you to manually throw the error without it being prevented 
from reaching the console, like so:

     future.done(null, function(e) { throw e; })

Maybe I'm bike-shedding - I need to convert some real-world code to use 
DOM Futures.

Sean
Received on Tuesday, 14 May 2013 03:14:39 UTC

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