Weak event listener

David Bruant bruant.d at gmail.com
Wed Mar 27 02:12:53 PDT 2013

Le 26/03/2013 23:50, Mark Miller a écrit :
> On Tue, Mar 26, 2013 at 10:14 PM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>     Le 26/03/2013 22:56, Mark S. Miller a écrit :
>         Because the weak-map-maker constructor grants no privilege and
>         can be generally accessible, whereas the weak-ref-maker grants
>         the privilege of being able to observe the non-determinism of
>         GC, and so should not be made accessible to code that
>         shouldn't have such powers. It is the same reason why Maps and
>         Sets, which are enumerable, enumerate their elements in a
>         deterministic order.
>         In short, separation of concerns as well as separation of
>         privileges.
>     If WeakMaps were granted the privilege of observing GC
>     non-determinism via iteration, I assume it would be through a
>     default WeakMap.prototype.@@iterator (that's how it works for Map).
>     Removing this authority can be done by providing another WeakMap
>     constructor with 'null' as WeakMap.prototype.@@iterator which is
>     pretty much as much work as removing access to the weak-ref-maker.
>     Thanks to the iterator protocol (and especially the @@iterator
>     symbol), privileges can be kept separate, so I don't think it's a
>     sufficient enough reason to not allow iteration over WeakMaps if
>     WeakRefs are in.
> WeakRefs are *not* in ES6, because getting these privilege separation 
> issues right is hard, and is best done after real experience using the 
> new module system.
I agree, but I don't see how it relates to what I wrote.
What I tried to described was that assuming the existence of privilege 
separation mechanisms (which I admit is a hard problem, but I assume it 
solved in my argument), then mixed-trusted code can be provided either 
less built-ins (like removing access to the WeakRef constructor) or 
different built-ins (like a new WeakMap constructor which doesn't have 
the same .prototype.@@iterator)

I make the assumption of a privilege separation 
mechanisms/features/tools because either they exist (Caja), or are 
planned (proxies, module loader). Regardless of how many tweaks these 
will need, a privilege separation feature is something we need in a way 
or another, so no matter how hard it can be to build, it will be built.

Do you agree that assuming the existence of privilege separation 
features, removing access to WeakRef or WeakMap.prototype.@@iterator is 
an equivalent amount of work?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130327/aa0a8d19/attachment.html>

More information about the es-discuss mailing list