Should go through TC39 strawman process and review before becoming normative.
From the November 19 2014 Meeting Notes:
"MM: In the absense of clear, we have a security property: the mapping from weakmap/key pair value can only be observed or affected by someone who has both the weakmap and the key. With clear(), someone with _only_ the WeakMap would've been able to affect the WeakMap-and-key-to-value mapping."
If that privacy/security property of Weak{Map, Set} is indeed a desirable feature, it should be specified as a *required* feature. Concretely:
(1) In the intro of Section 23.3 WeakMap [1], it should be added somewhere that no mechanism is provided that would either access or change a key/value pair of a WeakMap without providing both the key and the WeakMap. Ditto for WeakSet. In other words, it should be said that the privacy feature is *intended*.
(2) In Section 16.1 Forbidden Extensions [2], it should be added that conforming implementations must not provide such a mechanism. That would effectively outlaw the `.clear()` method (method that all major implementations currently provide).
[1]: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap-objects
[2]: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-forbidden-extensions
Hi Claude, I agree. Those would both be valuable changes.
Weakmap clear removed in rev29
I'm not particularly convinced that it needs to be forbidden in the manner suggested. Anyone who wants to enforce this property can do so simply by never exposing the actual weakmap to anyone other than trusted parties.
That would be expensive -- requiring wrapping the actual weakmap in a wrapper, and then creating an emulated WeakMap.prototype that contains only the allowed methods, which, when given an emulated WeakMap instance, accesses its encapsulated WeakMap using ... a WeakMap. At the very least, it would be ironic ;).
(function() {
"use strict";
const UnsafeWeakMap = WeakMap;
const hidden = new UnsafeWeakMap();
WeakMap = class {
constructor() {
hidden.set(this, new UnsafeWeakMap();
}
get(key) {
return hidden.get(this).get(key);
}
// etc...
};
})();
Every safe WeakMap operation becomes two builtin WeakMap operations.
Do you see a cheaper way to implement your suggestion?
(In reply to Mark Miller from comment #4)
> > ...
> Every safe WeakMap operation becomes two builtin WeakMap operations.
>
> Do you see a cheaper way to implement your suggestion?
that's just a single layer of encapsulation. That the sort of behavioral delegation that is done all the time with object based abstractions.
In reality, the "wrapper" probably some domain module object that exposes some other interface rather than the basic map interface.
(In reply to Allen Wirfs-Brock from comment #5)
> (In reply to Mark Miller from comment #4)
> > > ...
> > Every safe WeakMap operation becomes two builtin WeakMap operations.
> >
> > Do you see a cheaper way to implement your suggestion?
>
> that's just a single layer of encapsulation. That the sort of behavioral
> delegation that is done all the time with object based abstractions.
>
> In reality, the "wrapper" probably some domain module object that exposes
> some other interface rather than the basic map interface.
That may be some reality, but it does not address your own
> I'm not particularly convinced that it needs to be forbidden
> in the manner suggested. Anyone who wants to enforce this
> property can do so simply by never exposing the actual
> weakmap to anyone other than trusted parties.
which requires monkey patching to replace a hypothetical builtin weakmap with a safe one. That's the scenario that concerns me.
hypothetical builtin one with a .clear, that is.
fixed in rev29 editor's draft
'clear' method removed for WeakMap and WeakSet as per discussion at November 2014 TC39 meeting.
fixed in rev29