Re: document.body.appendChild(promiseForNode)

Bad idea for non-idempotent imperative operations, including appendChild.
The problem is that code such as

    node.appendChild(x);
    node.appendChild(y);

where node is known to be a genuine dom node, can be assumed to either
fail, or to append these children in order. However, with your suggestion,
if x is a promise, these children might both be appended but in reverse
order.

Given

    Q = Promise.cast;

when you don't know whether xP is a promise and you don't care about the
order,

    Q(xP).then(x => node.appendChild(x))

says what you mean rather explicitly. Depending on taste, you might instead

    Q(xP).then(node.appendChild.bind(node))

I prefer the first form.




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);
>
> What this would take is to add a preambule to every WebIDL operations,
> something like:
>     If at least one of the argument is a promise, then, execute the
> following:
>         var argsP = Promise.every(...args);
>         return argsP.then(operation);
> (so, the document.body.appendChild call above actually returns an unused
> promise)
>
> I sort-of like how generic this idea is. But, I have to ask:
> 1) how much of the web would this break?
> 2) how awful will performance of DOM/browser methods become? (more
> precisely, do implementors feel this is something they'll be able to
> optimize for easily?)
> 3) Does it make sense to apply the same thing for ECMAScript functions? I
> feel it could make sense for Date.setMonth, but maybe not for
> Array.prototype.push.
>
> Nothing comes to mind for 1). And I'll let the relevant people answer 2)
> as I don't feel qualified. I'm not entirely clear for 3)
>
> David
>
>


-- 
    Cheers,
    --MarkM