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

Re: Future feedback

From: David Bruant <bruant.d@gmail.com>
Date: Tue, 14 May 2013 13:29:14 +0100
Message-ID: <51922E1A.4090009@gmail.com>
To: Sean Hogan <shogun70@westnet.com.au>
CC: public-script-coord@w3.org
Le 14/05/2013 04:12, Sean Hogan a écrit :
> 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.
No worries :-) The discussion spread out in a lot of places.

>>> 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.
Oh... You would want .done to return the same future.
     f.done() === f
as opposed to what happens in then
     f.then(function(){}) !== f

I don't see a use for that. My experience with Q is that .done is used 
to end the promise "channel".

>> 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 does in the Q library. It will also with native support in 
combination with devtools.

Received on Tuesday, 14 May 2013 12:29:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC