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

On Mon, May 6, 2013 at 10:40 AM, Sam Tobin-Hochstadt <samth@ccs.neu.edu> wrote:
> On Mon, May 6, 2013 at 1:25 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> 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.
>
> This is silly in just the same way.  Given a promise, we can choose to
> wait for its result, or not, just as with a function, we can run it or
> not.

No. Existing promise libraries are built around the idea that the
calculation to create the value always happens, no matter if someone
has said they are listening to the promise or not.

So they do not provide the ability to postpone a calculation until
someone that has access to the promise requests the calculation to be
performed.

>> Nor have anyone brought forward any use cases.
>
> Consider a hash table that keeps some state remotely. Then a promise
> is useful for the results.  If promises for promises are impossible,
> can you store promises in the table?

This is similar to the example I brought up, except that you store the
values in a hash table rather than storing them in a database.

This is indeed an interesting use case. One relevant question is: What
is the use case for getting the promise stored in the hash/database,
rather than getting the value that the promise represents?

In your hash table example as a consumer I would think it's great if
what I get out of the API is values rather than promises so that I
don't have to bother with additional (recursive?) calls of .then().

One reason that was brought up was that if getting the promise from
the hash is fast, but getting the value from the promise is slow, then
the caller might want to know about the intermediate step of having
the promise from the hash.

So essentially this is a way of modelling progress by having several
nested promises. Each unwrapping callback represents an indication of
progress.

I'm not sure if this is a great way of modelling progress though. The
ProgressFuture that has been proposed seems like a more robust
solution to me.

/ Jonas

Received on Tuesday, 7 May 2013 22:04:31 UTC