More flexibility in the ECMAScript part? (was: Re: Futures
Mark S. Miller
erights at google.com
Thu Apr 18 08:01:54 PDT 2013
On Thu, Apr 18, 2013 at 7:45 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>> Note that Futures are entirely expressible in today's JS semantics.
> Even setting aside the event loop, this is arguable. Futures *as
> implemented in libraries today* are expressible, sure. That's a tautology.
> But there are cross-cutting issues at play, as Allen explained.
> In the case of Futures, there's that strange little method named `done`.
> The `done` method has always been conceived as a stop-gap solution for
> making "unhandled" rejections visible to the programmer. The usability of
> `done` is, well, not so great.
> It's quite clear that the garbage collector provides us with an upper
> bound on how long we must wait to know that a rejected future is truly
> unhandled. When the future is collected, then obviously no additional
> error handlers can be assigned to it.
> WeakRefs would give us just the information we need, but no consensus has
> been reached on them yet. Does it make sense to move forward with `done`
> when WeakRefs are sitting on the horizon? I don't have the answer, but
> these are the kind of cross-cutting issues that need to be carefully
> considered. Preferably on es-discuss. : )
I think we have informal consensus on the general functionality that
WeakRefs will provide and the security constraints they must not violate.
We still of course need to argue through many details. But the
non-controversial parts of WeakRefs are clearly adequate for the scenario
you have in mind -- except for one thing ;).
GC is never required to be complete. We must allow the collector to not
collect some unreachable objects. This means that, without .done, there's
no guarantee that an unseen-rejection bug will ever get diagnosed.
Therefore we still need .done.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss