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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
