Re: A Challenge Problem for Promise Designers (was: Re: Futures)

On Fri, Apr 26, 2013 at 3:27 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> From: David Sheets [kosmo.zb@gmail.com]
>
>> From my reading, DOM Futures doesn't state anything about resolution semantics, to its detriment, but abstracts those semantics behind `FutureResolver`.
>
> This is not correct. See "Let resolve be a future callback for the context object and its resolve algorithm." inside the resolve algorithm itself. DOM Futures are recursive, just like Promises/A+.

Ah, you are correct and this would appear to unnecessarily break
expected identities. Though, it's at least consistent instead of
special casing its own promises.

>> Have I presented this correctly?
>
> Yes.
>
>> Why is it a problem to specify a single level of assimilation instead of sometimes-flattening "thenables" but never flattening promises?
>
> The idea is that conformant libraries may want to prohibit promises-for-thenables (since, as discussed many times already, they are nonsensical, unless you care more about monads than you do about promises---which all promise libraries I know of do not). To do so, two things must occur:
>
> 1. The library must never allow creation of promises-for-thenables. That is, it must not provide a `fulfilledPromise(value)` method, only a `resolvedPromise(value)` method. DOM Future violates this by providing `accept(value)`, but presumably TC39-sanctioned promises will not provide such a method..
>
> 2. The library must prevent thenables-for-thenables from turning into promises-for-thenables via assimilation. Instead, it must do recursive unwrapping.
>
> In this way, Promises/A+ allows promises-for-promises within a library, if that library allows creation of such things in the first place (like DOM Future does). But it does not allow promises-for-thenables, i.e. it does not allow foreign promises-for-promises to infect a library with multiple layers of wrapping. Multi-layered wrapping *must* stay within a single library..

Why is there a semantic distinction between my thenables and your thenables?

If someone is using nested thenables, presumably they have a good
reason. Promises/A+ acknowledges this possibility by allowing
own-promises to nest. If we are interesting in constructing the "most
standard" promises system, surely this system must grant other,
foreign systems the same possibility of nesting own-promises without
interference? Of course, these systems also control their own
resolution semantics and *could opt* to magically flatten all results.

Could you point me to some code that needs dynamic flattening?

I understand the need for automatic lifting and 1-level assimilation.
I use these a lot. I'm still fuzzy on the utility of flattening k
levels for dynamic k.

Thanks,

David

Received on Friday, 26 April 2013 14:53:49 UTC