Security Demands Simplicity (was: Private Slots)

Brendan Eich brendan at mozilla.com
Sat Jan 19 20:39:34 PST 2013


Allen Wirfs-Brock wrote:
> On Jan 19, 2013, at 6:02 PM, Brendan Eich wrote:
>> Frozen objects could even be promoted by a copying GC into read-only memory, with the OS virtualized hardware MMU providing greater integrity.
>
> But here you are talking about some broader from of immutability that presumably includes non-property per instance state (eg, "internal data properties") and any sort of "private" per instance state that the language provides.  Either of those go beyond what ES5 Object.preventExtensions or even Object.freeze  provides.

No, I'm talking about plain old Object instances that are frozen and 
live long enough.

>> More to the point, programmers may wish a frozen object o having properties p and q, and null or frozen prototype chain of known properties, never to grow property r. Whereas using weakmaps explicitly, of course one can call r.set(o, v) to set r's value to v.
>
> Right, they may. My point we is that we have to decide on all the characteristics of a "frozen" object before we can answer all of these questions.
>
> I like the fact that you used "r" as a name above because certainly a WeakMap can be used to define a relationship involving an immutable object o.  But we shouldn't be creating confusion by pretending that those relationships are the samething as a property of o or anyway part of o.

Quite agree.

>    Such a relationship is an independent entity that exists separately from o and can be defined independently of o.
>> If we are talking about private syntax only in classes, this may not matter. Either private symbols or weak maps suffice.
>
> I think a very important characteristic of classes is that they really are just sugar and don't have any special magic. We should try to maintain that characteristic.

That seems to be agreed upon by everyone (anyone dissent?).

>> But proxies can tell, and prototype-based inheritance works for private symbols but not weak maps.
>>
>> So even if we allow a frozen object to grow new private-symbol-keyed properties not in that object at the time it was frozen (or let's say the time Object.preventExtensions or its internal form was invoked), private symbols and weak maps are distinguishable. If they weren't, we surely would have no need for one or the other.
>
> Well, then we are probably debating about how much we agree with each other.  Weakmaps and private Symbols are totally different things.  Just because some problems can be solved with either one doesn't make them equivalent.

Agreed, but the live proposal here is to use weakmaps for class private 
instance methods/variables, and not have private symbols.

> But, that said, you certainly could use Weakmaps to define a style of relationship that supports inheritance like mention above.  Just create a subclass of Weakmap like:
>
> class WeakMapWithKeyInheritance extends Weakmap {
>     has(key) {
>        if (super.has(key)) return true;
>        let proto = Object.getPrototypeOf(key);
>        If (proto === null) return false;
>        return this.has(proto);
>     }
>     get(key) {
>        if (super.has(key)) return super.get(key);
>        let proto = Object.getPrototypeOf(key);
>        If (proto === null) return false;
>        return this.get(proto);
>     }
> }

Right, but could you have "classes as sugar" including private syntax as 
David proposed (based on weak maps) that can access prototype-delegated 
properties? (I guess they would be 'protected' in that case.)

/be


More information about the es-discuss mailing list