On Tue, Mar 26, 2013 at 10:14 PM, David Bruant <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.



>
>
> David
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130326/9628d91e/attachment.html>

On Tue, Mar 26, 2013 at 10:14 PM, David Bruant <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.