Use cases for WeakMap

Brendan Eich brendan at mozilla.com
Mon May 16 00:19:45 PDT 2011


On May 16, 2011, at 12:08 AM, Erik Corry wrote:

> 2011/5/16 Brendan Eich <brendan at mozilla.com>:
>> On May 15, 2011, at 11:55 PM, Erik Corry wrote:
>> 
>>> 2011/5/16 Brendan Eich <brendan at mozilla.com>:
>>>> On May 15, 2011, at 3:48 PM, Oliver Hunt wrote:
>>>> 
>>>>> On May 15, 2011, at 3:47 PM, Boris Zbarsky wrote:
>>>>> 
>>>>>> On 5/15/11 2:20 PM, Rick Waldron wrote:
>>>>>>> Thanks Brendan, I was looking for something that was representative of
>>>>>>> Boris's use-case
>>>>>> 
>>>>>> A typical example is an extension wanting to associate some state with a DOM element or a Window without polluting the DOM.  For example, Adblock Plus wants to store some state per-element so that it knows when it's in the middle of unblocking something so it'll allow the load through for that one thing only.  Firebug wants to store some state per-window (e.g. script bodies, etc) and discard it when the window goes away.
>>>>> Which is a use case private names would achieve much more succinctly than weakmaps.
>>>> 
>>>> Not if the object is frozen.
>>> 
>>> That shouldn't prevent you adding private names.  See earlier message
>>> in this thread.
>> 
>> Now we are going in circles. Let's try to use words already defined in ES5 and model things in observably distinguishable ways, or what's the point?
> 
> Are you saying the way that private names work is off limits because
> the decision has already been made?

No, I'm saying clearly that [[Extensible]] being false means something in the spec, and in any future spec that includes private names.


> I'd appreciate if you responded to my earlier mail in this thread
> where I explained the thinking behind allowing private names on frozen
> objects, rather than just saying it's impossible by definition.

I'd appreciate it if we all followed the history of the big argument about private names vs. soft fields (weak maps). There's a lot to digest, and it is not about "possible" -- it's about what words mean.

If private names are spec'ed so they can be implemented by weak maps or secretly-extensible frozen objects, and no one can tell the difference, then there's nothing to argue about. But if you read the wiki and the threads here, clearly we have disagreements on reflection vs. encapsulation, at least. We also have disagreed (and perhaps finally agreed) on whether dot and bracket syntax should be mapped to weakmap transposed get and set.

Sam Tobin-Hochstadt a while ago pointed to a crucial experiment in a message I won't dig up right now:

function get(obj, id) {
    return obj[id];
}
function set(obj, id, val) {
    obj[id] = val;
}
var obj = Object.freeze({});
var privateName = ...;
set(obj, privateName, 42);
alert(get(obj, privateName));

Can this work with private names? Should it?

The private names proposals were already subject to a deathmatch attempt that ran roughshod over this disagreement. Let's not do it again.


>>>> Unless you then overspecify private names *as* weak maps, in which case we are going in circles :-P.
>>> 
>>> Allowing private names on frozen objects doesn't imply the GC
>>> semantics of weak maps so there is still a very important difference.
>> 
>> Not observable.
> 
> The GC properties of weak maps are hard to describe in the standard,
> but they are important to the users and the implementers so I hope
> they are not off limits for the discussion.

My point is not about GC semantics, it is about observable "frozen object gains property with private name" behavior. This is the bone of contention.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110516/15d6ef4b/attachment.html>


More information about the es-discuss mailing list