Weak references and destructors

Brendan Eich brendan at mozilla.com
Thu Dec 10 11:38:42 PST 2009


On Dec 10, 2009, at 11:27 AM, Mark S. Miller wrote:

> By all means, let's continue hashing it out. I posted this proposal  
> to es-discuss and presented it to the committee some time ago. I do  
> not recall any serious objections, and I do recall several positive  
> responses. However, the committee has not yet made any decision. If  
> there were serious objections I have forgotten, my apologies, and I  
> ask that you (re?)post them to es-discuss.

Allen had some thoughts, but we were out of time at the last face to  
face. I'll let him speak for himself.

The issue that I raised at the last meeting, other than naming nits  
(which we can defer for now), was in response to this:

  "All visible notification happens via setTimeout() in order to avoid  
plan interference hazards. Side effects from these notifications  
happen in their own event-loop turn, rather than being interleaved  
with any ongoing sequential computation. However, this requires us to  
promote setTimeout() and event-loop concurrency into the ES-Harmony  
specification, which is still controversial."

from http://wiki.ecmascript.org/doku.php?id=strawman:weak_references.

We may not standardize the execution model to the degree you hope.

We also may not agree on notification being guaranteed. At the last  
f2f I mentioned how generators in JS1.7+ have a close method, again  
after Python, but without the unnecessary GeneratorExit built-in  
exception object thrown by close at a generator in case it has yielded  
in a try with a finally. Naively supporting notification guarantees  
creates trivial denial of service attacks and accidents.

Of course, we could say the universe ends without pending  
notifications being delivered, but in the effecttful browser, the  
multiverse goes on and there are lots of channels between 'verses ;-).

In general I'd like to decouple weak references from hairy execution  
model issues. If we can't do this, then the risk we'll fail to get  
weak refs into the next edition go up quite a bit. The obvious way to  
decouple is to underspecify.

/be

> There is one very good suggestion from Cormac Flanagan (cc'ed) that  
> I have yet to incorporate that would make the specification much  
> simpler and clearer. Or, Cormac, please feel free to modify the wiki  
> to incorporate your proposal. Since Cormac's proposal doesn't really  
> affect the meaning of the proposal or how programmers would use the  
> API, we should proceed to hash out this proposal now.
>
> If we seem to have approximate consensus here on es-discuss, then I  
> propose we try to make a decision on this at the next committee  
> meeting. (At this stage, a positive decision operationally means  
> moving it from "strawman" to "proposals".) Istvan & John, I'm cc'ing  
> you to request this be put on the agenda. Thanks.
>
> -- 
>    Cheers,
>    --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091210/2341b2ae/attachment-0001.html>


More information about the es-discuss mailing list