Re: Future feedback

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.

David

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