Questioning WeakMap.prototype.clear

David Bruant bruant.d at gmail.com
Tue Jan 22 10:53:27 PST 2013


Le 21/01/2013 22:42, Allen Wirfs-Brock a écrit :
> On Jan 21, 2013, at 12:25 PM, David Bruant wrote:
>
>> Le 21/01/2013 20:52, Allen Wirfs-Brock a écrit :
>>> On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote:
>>>
>>>> This is the reality check I can get behind—I'm hard pressed to come up with a use case that isn't contrived or solvable by some other means.
>>>>
>>> This is easy:
>>>
>>> I'm do phased traversals over a complex data structure.  I have a number of functions that collaborative perform the function and they share access to a WeakMap to cache relationships that they identify over the course of the traversal.  When I start a new traversal phase I want to flush the cache so I use the clear method to do so.
>> Creating a new weakmap would work equally well to flush the cache.
> Same arguments applies to Map clear.
The difference with maps is that one can already enumerate all the keys, 
the .clear is just a convenience, not a new capability

> I'm actually more comfortable with a discussion of the utility of the clear method for maps, in general.  But, if it has utility for Map then it has the same utility for WeakMap and supplying on both is a matter of API consistency.
Again, I don't think maps and weakmaps can be compared. They are 
different tools that can be used in different conditions. Like unique 
and private symbols.
My (small) experience is that when I need to associate data with an 
object but don't want to do the book-keeping of which entry I care 
about, I use weakmaps. So far, I've only used maps in places where I 
used to use objects to associate string with data. So far, I've used 
maps as a safe object (no need to worry about inheritance or __properties__)

WeakMaps methods can't use anything else than objects as keys, it makes 
very hard to switch from a structure to another and I still haven't 
found a case where I would have traded one for the other.

I'll fork a new thread about GC-related performance.

David


More information about the es-discuss mailing list