Weak event listener

David Bruant bruant.d at gmail.com
Tue Mar 26 15:14:13 PDT 2013

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.


More information about the es-discuss mailing list