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: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 3 May 2013 07:56:26 -0700
Message-ID: <CAAWBYDDLJYKjPOvCLUXqUj5dQuGmAQ9XjL3+V-hjCRpL9LUAsw@mail.gmail.com>
To: "Mark S. Miller" <erights@google.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 5:02 PM, Mark S. Miller <erights@google.com> wrote:
> On Thu, May 2, 2013 at 4:44 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Thu, May 2, 2013 at 4:39 PM, Mark S. Miller <erights@google.com> wrote:
>> > Tab Atkins said:
>> >> 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?
>>
>> Because I'm trying to figure out what they should do!  But you keep
>> answering my attempts with responses that say, roughly, "Well, you
>> can't have nested promises anyway, so the question is moot.".  >_<
>
>
>
> Ok, Tab, this is getting close enough that I think we can hold a good tone
> and get back asap to tech discussions. Given what you're trying to say, how
> about a hypothetical:
>
>    What if we did have an unconditional lift operator....
>
> I hope you appreciate the difference between this and your earlier
>
>     "you *can* do it in Futures,"
>
> Let us all proceed assuming that this hypothetical is in good faith, and
> everyone on all sides is open to changing their mind on this.

The *intention* of that statement is "one of the specs we're
discussing has such an operator, so let's discuss it".  I find it
useful to refer to existing stuff when possible, rather than phrasing
everything hypothetically and abstractly, as I find it helps keep
terms clear.  Nobody has to wonder what I mean when I say
"unconditional lift operator" if I just say "Future.accept()" instead.

Plus, it's frustrating when I ask a question like "Is there any
use-case for recursively flattening native promises?" and get a
response of "No", when what is really meant is "No, because there's no
such thing as a nested promise anyway.".  Those are completely
different responses - one is agreeing with me, the other disagreeing!
By keeping the discussion pointed at the Futures draft, I hope to
avoid misunderstandings like that - there *is* such as a thing as a
nested Future, given the current state of the spec, so we can usefully
discuss how that might act, without confusion.

This is why I keep asking you and everyone else in the conversation to
take my words as politely as possible.  If the existence of the
Futures spec offends, do not presume I mean offense by mentioning it.
If one believes that the Futures spec is a territory grab, presume
that I don't care and am just talking about different proposals
without regard to their origin.  I don't like having to walk through a
minefield of confusing offense when I just want to argue. ^_^

~TJ
Received on Friday, 3 May 2013 14:57:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC