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: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 6 May 2013 10:25:51 -0700
Message-ID: <CA+c2ei9=nQK-mUXrdFb5RN0j9mLZqjOXk_y6OtUioKjxAC1T9w@mail.gmail.com>
To: Sam Tobin-Hochstadt <samth@ccs.neu.edu>
Cc: "Tab Atkins, Jr." <jackalmage@gmail.com>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller" <erights@google.com>
On Fri, May 3, 2013 at 7:10 PM, Sam Tobin-Hochstadt <samth@ccs.neu.edu> wrote:
> On Fri, May 3, 2013 at 7:17 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> Third, there's the question of what a nested promise actually means.
>> Normally a promise represents "a value after some time". But what does
>> a nested promise mean? "A value after a longer time" obviously isn't
>> correct since there are no time constraints associated with a promise.
>> "A promise after some time" also isn't really meaningful given that
>> that simply means "A value after some time after some time".
>
> I've been staying out of all of the promises discussions, but this
> just doesn't make any sense at all.  A function of no arguments is a
> "computation that produces a value".  By a similar argument to yours,
> functions of no arguments that produce the same aren't meaningful,
> because it's a "computation that produces a computation that produces
> a value".  I hope we can all see that this in fact makes perfect
> sense.

The difference is that it's meaningful for a function that takes no
argument to return a function that takes no argument. That provides
the capability for the caller of the initial function to determine
when the returned function should be called. Thus it lets the caller
postpone the CPU cycles spent by the returned function until the
result is actually needed.

To put it another way a "computation that produces a computation that
produces a value" is meaningful since you can choose to not perform
the second computation if it turns out that you don't need it.

And then there's of course the fact that in many languages functions
can have side effects, and so the caller of the first function can
choose to have the side effects from the returned function happen at a
desired time.

None of these use cases apply for promises.

But I can agree that using sentence parsing to make my point might not
have been the best way to do it. But my point still stands that
promises that return promises doesn't appear to have any useful
semantics. Nor have anyone brought forward any use cases.

/ Jonas
Received on Monday, 6 May 2013 17:26:50 UTC

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