Re: Futures

On Mon, Apr 22, 2013 at 1:53 PM, Kevin Smith <zenparsing@gmail.com> wrote:

>
>  I would love to see this, but best I can tell it can't be a
>> straitforward polyfill. The necessary infrastructure has to settle, and
>> what are Promises/A+ implementers supposed to do in the meantime?
>>
>
> Presumably the standard version of Future would provide some convenient
> way to get the symbol.  The library would use that to conditionally provide
> the symbol-named alias.  Something along these lines:
>
>     if (typeof Future !== "undefined")
>         MyPromise.prototype[Future.thenSymbol] = MyPromise.prototype.then;
>
> No?
>


Perhaps, depending on how all the current libs are being used in the wild.
But this assumption does breaks the ducktyping as defined by the spec. Who
knows -- this may not be a problem in practice.

Alternatively it occurs to me that now that we'll have mutable __proto__ to
lean on we could specify something like Promises/A++ as Promises/A+ with
the additional constraint that some Promise (or Future, or whatever)
builtin exist on the proto chain of any promise. This would allow for
instanceof checks to be interoperable across libraries. And really, you
don't even really need mutable __proto__ -- this is only necessary for
pure-userland interoperability. Since this a standard builtin the problems
with Promises/C go away -- even when polyfilled all promise libs could
expect to see the same base class. That is, IIRC -- it's been a *long* time
since I've really chewed this over.

So I guess I'm less skeptical. Promise (and an accompanying Promise.when)
could be defined and shimmed into existing tool chains today. A huge chunk
of currently working Promises/A+ code would break without a corresponding
Promise.prototype.then, but nothing would stop lib authors from adding it.
And even without it the migration path would be straightforward and could
even be automated.

Okay, I'm convinced. But I don't matter -- both TC39 and the Promises/A+
implementers have to be.