If you don't want to expose clear on a WeakMap, create a subclass that doesn't
support it:
class WeakMapWithoutClear extends WeakMap {
delete() {throw Error("Clearing this map is not allowed");
}
if you are really paranoid that somebody is going to do
WeakMap.prototype.clear.call(myWeakMapWithoutClear);
then don't expose myWeakMapWithoutClear to untrusted parties or only expose
wrapper object that hides the WeakMap as private state.
clear is an operation that can not be otherwise synthesized for WeakMaps.
Given the ambient impact of the mere existance of WeakMap entries on garbage
collection algorithms, it seems likely that will be performance advantages in
some situations to proactively clear a WeakMap rather than waiting for the GC
to do so. Having clear enables this while it doesn't prevent using WeakMaps in
ways that don't expose that operation to ambient use.
On Jan 21, 2013, at 3:04 AM, David Bruant wrote:
> Le 21/01/2013 11:58, David Bruant a écrit :
>> Before the clear method, weakmaps had the following property: "you can only
>> modify a weakmap entry if you have the key". This property isn't true
>> anymore with .clear. This may be considered as abusive ambient authority.
> Let's see how this feature came to appear:
> Jason Orendorff talked about Map.prototype.clear [1] (Oct 22nd). Seen as a
> good idea. No discussion on whether it's a good idea for WeakMaps
> specifically. Nicholas Zakas briefly mentions it in November [2]. No one
> replied to it specifically. I haven't seen any discussion about it in meeting
> notes [3]. A brief mention of Set/Map.prototype.clear [4] as a review of the
> Oct 26th draft [5] (note, 4 days after Jason post, which is a very short
> amount of time) but nothing about WeakMap.prototype.clear. Implemented in
> Firefox soon after [6]...
> I think WeakMap.prototype.clear slipped through the crack without being
> specifically discussed. Based on what's publicly available, I don't see
> anyone noticed and discussed the fact that WeakMap.prototype.clear questions
> the property that was true before its adoption ("you can only modify a
> weakmap entry if you have the key")
As much as makes sense we want Map, WeakMap, and Set to expose the same
interfaces. Any new method added to one is going to get added to all of them,
unless it either simply makes no sense for one of them or if somebody can make
a convincing argument for excluding it for one of them.
>
> I think the property I mentioned is cricial to weakmap integrity and I think
> WeakMap.prototype.clear should be considered for removal... or at least
> proper discussion since none really happened from what I've found.
TC39 doesn't have a process that requires a priori discussion on es-discuss of
every design detailed before it can become part of specification draft. I'm
pretty sure we would never finish anything it that was the case. The spec.
drafts exist so the actual details of the proposed specification an be reviewed
and discussed like this.
Allen
>
> David
>
> [1] https://mail.mozilla.org/pipermail/es-discuss/2012-October/025962.html
> [2] https://mail.mozilla.org/pipermail/es-discuss/2012-November/026114.html
> [3] https://github.com/rwldrn/tc39-notes
> [4]
> https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-11/nov-27.md#review-of-new-draft-spec
> [5] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=814562
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
