Questioning WeakMap.prototype.clear

David Bruant bruant.d at gmail.com
Mon Jan 21 09:40:43 PST 2013


Le 21/01/2013 18:02, Allen Wirfs-Brock a écrit :
> 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.
Since the use of .clear isn't mandatory, implementors have an incentive 
to optimize weakmaps in which clear isn't used. It's possible that 5-10 
years from now, implementors realize that .clear provides no performance 
benefits.
If performance is the main reason to introduce, why not wait until 
performance actually becomes a bottleneck? Something about premature 
optimizations.


>   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.
Maps and WeakMaps don't even have the same signature for the 
get/set/has/delete methods in which the former accepts non-objects as 
key while the latter doesn't! Maps and WeakMaps are very different 
features for different usages. I don't think I've encountered a case 
where I could switch one for the other. If someone has such cases, can 
they share them to the list?
I guess it's an equivalent debate than the recent one about unique and 
private symbols. Unique symbols are collision-free property names and 
avoiding collision is the only good reason to use them, otherwise, 
strings will do the job fine; private symbols are about encapsulation 
for which neither strings nor unique symbols are relevant.
Different features, for different usages; I don't think it's a sane 
default to map interfaces whenever possible. I think the default should 
be to carefully consider if a method in one case is relevant for the 
other. Where I agree is that similar functionality should have the same 
name in these sibling interfaces.

>> 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 don't want discussion on es-discuss to be a requirement; there is no 
mention of WeakMap.prototype.clear specifically with the issues I raised 
in meeting notes. I guess TC39 agrees on the "Any new method added to 
one is going to get added to all of them, unless...". I hope TC39 would 
reconsider this position given what I said above.

David


More information about the es-discuss mailing list