Argument in favor of adding "has" in the WeakMap API

David Bruant david.bruant at
Wed May 11 12:38:51 PDT 2011

Le 11/05/2011 20:38, felix a écrit :
> On Wed, May 11, 2011 at 11:16, David Bruant <david.bruant at> wrote:
>> A memoizer could be written to improve f time performance (by the cost of
>> memory, of course).
>> ----
>> function memoizer(f){
>>   var cache = WeakMap();
>>   return function(o){
>>     var res;
>>     if(WeakMap.has(o))
>>       return cache.get(o);
>>     res = f.apply(this, o);
>>     cache.set(o, res);
>>   };
>> }
>> ----
> I'm not sure I understand your code.
> it's not clear to me why you need .has at all, since you can check the
> return value of .get instead.  in the case where 'undefined' is a
> valid value that you would want to memoize, you can store a unique
> object to represent 'undefined'.
The ambiguity of "get" returning "undefined" when the key is actually
undefined or when it is defined but its value is "undefined" already
happened with objects. The solution to that was the "in" operator (or
Object.prototype.hasOwnProperty depending on cases). I'm just asking an
equivalent for weak maps. I agree its not necessary as proved in
harmony:weak_maps#explicit_soft_own_fields . However, a native
implementation would be a good addition.

> also, memoization is usually caching on argument values rather than
> argument identity,
I consider that the most important word in your sentence is "usually".
Just to clarify, the argument is either a primitive value
( or an object. Memoization is usually
caching on primitive value. Caching on objects could have been an idea,
but it would have created a (potentially big) memory leak and lookup
would have been linear. Now, with WeakMap, memoizing on objects doesn't
leak memory (the gc comes to clean the weak map for you!) and lookup is
handled by the engine which means it is at worst O(log(n)) and certainly
constant and small in practice.

> but weakmap lookups are by object identity not
> object value.  You can't use non-object keys in a weekmap, so in order
> to gain the benefits of the memoization above, a caller would have to
> be careful to avoid constructing new objects with the same values, and
> somehow keep re-using the same argument objects, which is pretty
> inconvenient for typical uses of memoization.
So you say. I'd like a proof of that statement. Anyway, I am not saying
that object-based memoization will solve all problems. But if people
have a use case for it, why not. Once again, above you said "usually";
we are so used to not have these kinds of things (WeakMaps, maybe other
features) that we've found workaround over the years. It may be time to
question these choices in our library/applications and see if weak maps
aren't a good fit now that we have them (or are about to).

Regardless, if people want to use object-identity-based memoization and
it forces them to think of their object instanciations more carefully
than creating new objects all the time, then I see this as a benefit,
not a problem.

"Reusing when possible instead of creating new things to serve the same
purpose". Sounds like I want to save the planet from consumerism :-)


More information about the es-discuss mailing list