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

# 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?


David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to