- From: David Bruant <bruant.d@gmail.com>
- Date: Mon, 02 Sep 2013 21:47:41 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Le 02/09/2013 21:19, Tab Atkins Jr. a écrit : > On Mon, Sep 2, 2013 at 10:56 AM, David Bruant <bruant.d@gmail.com> wrote: >> Hi, >> >> I apologize in advance if this has been discussed already, I'm a bit behind >> regarding promise discussions. >> >> As far as I know, currently, standard functions that expect an object of a >> given type will throw when passed a promise. However, wouldn't it be elegant >> to do: >> >> var dataP = getData(url1); // http GET >> var templateP = getTemplate(url2); // http GET >> var nodeP = Promise.every(templateP, dataP).then(compileTemplate); >> document.body.appendChild(nodeP); > Why not instead just do: > > var dataP = getData(url1); // http GET > var templateP = getTemplate(url2); // http GET > var nodeP = Promise.every(templateP, dataP) > .then(compileTemplate) > .then(node=>document.body.appendChild(node)); It is not mutually exclusive :-) I have often found myself in the following situation: I write a function expecting a value and later realize that I may not have the value at hand right away when calling and decide to wrap the arguments with Q.when. As you say, the alternative is for the consumer code to adapt. The question is whether we want the boilerplate on the inside (the change I described) or on the outside (.then(node=>document.body.appendChild(node));) It really isn't clear to me which is best. I wonder if type inference magic can remove the async inside boilerplate in practice (if you can prove that the context in which a built-in is called doesn't involve promises, just provide the sync version directly). The cost (readability + runtime) of the outside boilerplate doesn't seem removable however. David
Received on Monday, 2 September 2013 19:48:10 UTC