Le 20/06/2013 14:55, Forbes Lindesay a écrit :
>
> I've been answering quite a few questions about promises on stack 
> overflow lately.
>
Do you have a link to a list to these questions (and/or your answers) 
off-top your browser history by any chance?

> One of the key things people seem to struggle to get their head around 
> is the idea of `.then` as being something that transforms the promise 
> and returns a new promise.  They either expect it to mutate the 
> existing promise or they expect it to behave like `.done()` does.
>
I wasn't there when that started, but it feels like "then" organically 
grew out of the experience of using promises a lot which naturally leads 
to promise pipelining.
It doesn't feel like the most "fundamental brick" to understand what 
promises are (what .done looks like though), because it isn't.
At a first approximation, people can use .then the way the expect 
(without caring for the return value)

> I think `.done()` could be extremely useful purely as a teaching 
> device.  If we started everyone off by learning to use `.done()` they 
> would have a much shallower learning curve.  Initially they'd get all 
> their errors thrown immediately which would be easier to see.
>
That's how Q behaves out of necessity, but native promises can have 
better integration with debugging tools and don't need to reflect the 
error at runtime.

> It would be much more similar to typical (but terrible) DOM APIs and 
> jQuery APIs that are event based or have a callback and an errback.  
> Having learnt to use `.done()` we could teach `.then()` as a more 
> advanced feature that let you compose asynchronous operations by 
> returning a promise that has been transformed by the callbacks.
>
.then can be taught without telling it returns something ;-)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130620/dce3a5f0/attachment.html>

Forbes Lindesay:
> I've been answering quite a few questions about promises on stack 
> overflow lately.

Do you have a link to a list to these questions (and/or your answers) 
off-top your browser history by any chance?

I wasn't there when that started, but it feels like "then" organically 
grew out of the experience of using promises a lot which naturally leads 
to promise pipelining.

It doesn't feel like the most "fundamental brick" to understand what 
promises are (what .done looks like though), because it isn't.
At a first approximation, people can use .then the way the expect 
(without caring for the return value)

> I think `.done()` could be extremely useful purely as a teaching 
> device.  If we started everyone off by learning to use `.done()` they 
> would have a much shallower learning curve.  Initially they'd get all 
> their errors thrown immediately which would be easier to see.

That's how Q behaves out of necessity, but native promises can have 
better integration with debugging tools and don't need to reflect the 
error at runtime.

> It would be much more similar to typical (but terrible) DOM APIs

.then can be taught without telling it returns something ;-)