Re: Promises: Auto-assimilating thenables returned by .then() callbacks: yay/nay?

On Thu, May 2, 2013 at 3:39 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> From: Jonas Sicking [jonas@sicking.cc]
>
>> (... lots of really good stuff ...)
>
> I agree with everything you wrote, both in the technical content and in the tone. I appreciate the tone as a counterpoint to the two extreme voices we've heard from so far, and in particular it's great you've given some perspective on the WebApps WG process which I don't think many people in this discussion have. It's also really good that you phrased things as "noodling over the Future API" instead of "we produced a spec, you didn't, so STFU".

Argh, this was in no way the intended tenor of my emails.  This is
why, in previous emails, I went out of my way to explicitly say "hey
everyone, please interpret these as politely as possible, because
sometimes it's hard to disagree without the text sounding rude".

Please reinterpret my previous email (and all other emails I ever
send) in the politest way possible.  ^_^

> The issue of whether a way to create promises for promises is an important one, and I fear that if DOMFuture continues to allow it, speculative-TC39-promises will be forced to include recursive implicit thenable assimilation in order to prevent such entities, which have made it into the wild of the web via DOMFutures, from infecting the program. But that aside, the issue of whether to assimilate thenables implicitly or explicitly can be considered separately from DOMFuture's promises-for-promises abilities.

You have said in the past (again, I can bring up emails if necessary,
so we're all clear on what's being talked about) that recursive
assimilation of non-native thenables is required.  Regardless of what
else goes on, we'll have recursive assimilation.

The relevant questions are:  do we recursively flatten native promises
too?  (Let's, please, assume that it is possible to make nested
promises.  Saying "but you can't" isn't helpful, because you *can* do
it in Futures, and the "monad camp" wants it.)  And: do we
automatically assimilate thenables ("promise-likes") returned by a
.then() callback?

> And as for your summary of the original question in this thread, of whether thenable assimilation should be done by the promise implementation: it's a good summary. I do want to add one more thing: thenable assimilation only works if `then` is a function, so it's less dangerous than `__proto__` in that sense. May be small consolation to some, but seems important. Otherwise I will not repeat arguments that have happened elsewhere.

Not a significant difference, I think; if you call a property "then",
it's most natural for it to be a method - in indicates some form of
chaining behavior, which means it needs to be a function.

The fact that "__proto__" has dunders, while "then" doesn't, makes the
"magic property" problems even worse. :/

On Thu, May 2, 2013 at 3:51 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> From: Domenic Denicola [domenic@domenicdenicola.com]
>> I do want to add one more thing: thenable assimilation only works if `then` is a function, so it's less dangerous than `__proto__` in that sense.
>
> In particular, it means `return JSON.parse(userData)` will never trigger the thenable assimilation, since `JSON.parse` will never return something whose `then` property is a function.

Ah, yeah, JSON wont' trigger this.  But any class that purposely
includes a .then property in its instances, will probably have the
.then property be a method, I think.  (And we already know of at least
one class that does this.)

~TJ

Received on Thursday, 2 May 2013 22:55:24 UTC