Private symbols as WeakMap sugar

David Bruant bruant.d at
Wed Jan 16 00:11:59 PST 2013


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);

# Benefits

## Private symbols are out

No need for the specific freeze behavior.
No need for the unknownPrivateSymbol trap.
Unique symbols do remain though

## MarkM's hint

The use of a different syntax for a different usage would be the hint. 
It's possible that both syntax will be used, but in all likelihood, only 
one syntax will be used per weakmap, clearly indicating to the engine 
which storage and implementation characteristics should be preferred. 
Worst case, the performance of unclear code is a bit worse.

## Inheritance

Both "o[wm]" and "wm in o" could desugar to a slightly more useful 
algorithm involving proto-climbing thus emulating inheritance as we know it.

     var w = new WeakMap();
     var o = {};
     o[w] = 37;
     var o2 = Object.create(o);
     console.log(o2[w]); // w.has(o2) returns false, w.has(o) return 
true. w.get(o); logs 37.

# Downsides

## Object.defineProperty & friends don't work with weakmap as property name

No getter/setter, no configurability, no hasOwnProperty. I see that as a 
benefit actually. YMMV
It makes weakmaps-as-private-symbol inconsistent with unique symbol. I'm 
also ok with this.

## Confusion?

Maybe people will be confused by this bi-use of the same feature. Maybe 
the sugar will result in everyone using it and not caring of 
WeakMap.prototype methods, defeating the "hint" point above.

# Open question

## What happens when the WeakMap is wrapped?

     var w = new WeakMap();
     var ww = new Proxy(w, {});
     var o = {};
     o[ww] = 12; // ww.set(o) calling the ww's set trap?
     // should a/4 new trap(s) be created for internal weakmap methods?


More information about the es-discuss mailing list