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

On Sat, May 4, 2013 at 1:48 AM, Claus Reinke <claus.reinke@talk21.com> wrote:
>> There are several problems with nested promises.
>>
>> First off they force people to answer the types of questions that
>> arise in this thread: How do I get to the value inside the doubly
>> nested promise? Which functions recursively assimilate and which
>> don't? How do I ensure that my nested promise doesn't get accidentally
>> unwrapped? Does that matter?
>>
>> I.e. permitting nested promises creates a more complex model and with
>> that you always get more confusion and more questions.
>
>
> From the perspective of a-promise-is-just-like-other-wrapper-classes,
> auto-flattening promises creates a more complex model with more
> confusion (when are my data-structures safe from interference? when
> do heuristics for flattening get in the way?) and more questions (why do my
> data structures get destroyed?).

I can absolutely agree with this. If we think of promises as just
another wrapper class then a simpler model would be to never
automatically flatten. And a lot of the complexity that is involved
here stems from the fact that the API is trying to "be helpful", like
you are referring to further down. I'm generally not a fan of APIs
that try to "be helpful" since very often that helpfulness just ends
up getting in the way.

The way I tend to think of such "helpfulness" is that you better be
*very* sure that it's actually doing the right thing. The harm such
helpfulness causes when it does the wrong thing, is generally much
larger than the helpfulness it provides when it does the right thing.

The "helpfulness" of the Future API consists of, as far as I can tell,
of the fact that FutureResolver.resolve() accepts either a value or a
promise and "figures out" whether it needs to unwrap the promise or
not. Likewise that Future.then() does the same thing with the return
value from a returned from the registered callbacks.

However further down you say

>> The fact that .then() will unwrap the return
>> value 0 or 1 layers would likely have to change such that it always
>> unwraps one layer and never accepts raw values.
>
>
> This would be preferred by some, although others have pointed out that if a
> library can identify its own Promises, such a change would not be necessary:
> as long as the callback result is not an own Promise, the library may wrap
> it.

So here you are arguing that the helpfulness isn't actually damaging
as long as you are only using one promise library. However none of the
arguments in my email relied on confusion between incompatible promise
libraries, so I don't see how that's related.

So I'm sure what helpfulness you are arguing should be removed.

While I in general agree that helpfulness of APIs is generally a bad
thing. I actually think we have enough experience to be confident that
the helpfulness of the promises API actually does the right thing
enough of the time that it is a good idea.

I.e. the only place where I've seen it break down is when trying to
support promises-of-promises, but given that no use cases have been
brought forward, that doesn't concern me much.

/ Jonas

Received on Monday, 6 May 2013 17:48:19 UTC