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

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
>



-- 
    Cheers,
    --MarkM