Private symbols as WeakMap sugar

Claude Pache claude.pache at
Mon Jan 21 06:29:31 PST 2013

Le 21 janv. 2013 à 11:58, David Bruant <bruant.d at> a écrit :

> Le 21/01/2013 10:05, Claude Pache a écrit :
>> Le 16 janv. 2013 à 09:11, David Bruant <bruant.d at> a écrit :
>>> Hi,
>>> This is an idea naturally derived of all the current discussions about WeakMaps and Private symbols. The proposal is easily summarized by these lines of code:
>>>    var wm = new WeakMap();
>>>    var o = {};
>>>    o[wm] = 12 // desugars to wm.set(o, 12)
>>>    var a = o[wm]; // desugars to wm.get(o);
>>>    wm in o // desugars to wm.has(o);
>>>    delete o[wm] // desugars to wm.delete(o);
>>> <snip>
>> Hello,
>> I've just thought of a fundamental flow in the idea of using of weak maps instead of  private symbols, which I believe is enough for forcing to forget that idea, at least on a language design level.
>> (Note: I have not reread all what have been posted on this list on the subject since then, so I am not sure that someone has not already raised that objection.)
>> Weak maps and private symbols have completely different goals, and conflating the two features into one can (and, as I'll show,  will) lead to conflict of interest in designing the API. Weak maps are designed for better memory management, while private symbols are designed for better encapsulation. The key difference of philosophy between the two features is:
>> * In weak maps, you ***need not*** have access to the value if you don't have access to the key.
> Although I see it's crucial to understanding your point, I don't understand this sentence.

The basic idea of weak maps is that, as soon as you have lost explicit reference to some key, it can be garbage-collected. In order to achieve that without exposing GC mechanism, you typically avoid to give access to a key or its corresponding value if you are not able to provide explicitly that key. What I want to say, is that this is a mean, not a requirement (but apparently we disagree on that point, see below).

>> * With private symbols used as property keys,  you ***must not*** have access to the property value if you don't have access to the symbol.
>> It is just a happenstance that, in our case "need not" mostly implies "do not". The problem is that it is only "mostly". Indeed:
>> It is very reasonable to have a -clear() method on WeakMaps, which delete all relations defined by the weak map, in situation where you know that you won't need these mappings any more, but it would be impractical to either enumerate all the keys
> It's not possible at all to enumerate weak map keys. The good reason for that is that the set of keys depends on GC which is not deterministic (2 successive enumeration may randomly result in different enumerations).

Instead of "enumerate all the keys", I should have said "explicitly provide all the keys" (without the aid of some inexistent built-in enumeration mechanism).

>> or to wipe all references to the weak map. Good for memory management.
> 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.

If indeed this property ("you can only modify a weakmap entry if you have the key") is a goal of WeakMaps, my objection is void. Personally, I consider that property as a mean to achieve another goal, namely garbage collection of keys or values without the need of explicit revocation of the association key/value. But this issue is the subject of your next message ("Questioning WeakMap.prototype.clear"), where it will be more properly discussed.


>> On the other hand, you certainly do not want a ".revoke()" method available on every private symbols, which wipe all properties which use that key as private symbol, even on objects to which you are not allowed to have access. Bad for encapsulation.
> I agree for private symbols and I think it equally applies to weak maps.
>> There is no fundamental problem to use a feature for something very different that it was not designed for. But before sanctioning such a use in a language design, conflict of interest between the two intended use must be carefully considered.
> I agree with you. I starting exploring the idea with the expectation to get this kind of feedback. I still thinking of weakmaps with the get/set/has/delete interface and the property I mentioned above.
> David

More information about the es-discuss mailing list