W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

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

From: Mark S. Miller <erights@google.com>
Date: Thu, 2 May 2013 16:39:48 -0700
Message-ID: <CABHxS9ibxnavR2Dn+dj=ZbfV6X2fKaOFzGRVpZsZY5r2V1w5yg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, Jonas Sicking <jonas@sicking.cc>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Thu, May 2, 2013 at 3:54 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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".

Jonas, along with Domenic, I would like to thank you as well for shifting
tone, and for your clarification of history. I appreciate the reasons for
not withdrawing one draft standard until an adequate replacement appears --
provided that the draft is treated as tentative in the spirit stated in
your email.

> 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.  ^_^

Hi Tab, I am trying. I accept that you think there's nothing wrong with
your conduct. But see below.

> > 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,

This statement directly contradicts Jonas' account of what it means at this
stage in the process to be noodling on a draft standard. Are we discussing
what the standard should contain or not? This still comes across as you
making a non-negotiable demand that Futures will do unconditional lifting.
If you've already made up your mind about what Futures will and won't do,
why are we discussing it?

> 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 23:40:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC