Security Demands Simplicity (was: Private Slots)

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Jan 19 21:43:59 PST 2013


On Jan 19, 2013, at 8:39 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> ...
>> 
>> 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.
> 
>>   ...
>> 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.

Then we should be close to resolving that if we agree that WeakMap are primarily useful for represent external relationships between objects. The encapsulated state of an object isn't this sort of external relationship and presumably "private state" is the most intimate form of encapsulated state.  It would be very misleading to both ES programmer and implementors if what syntactically appears to be private state is specified to have the semantics of an external relationship.

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

Yes, its is closer to what "protected" means in some languages and we may want to add syntax at some point to make it easier to defined private/protected properties.  But it would be a very misleading and unexpected if that syntax was just sugar for WeakMap operations.  Nobody defines private state of a class with the expectation that it has the implementation cost of maintaining an external relationship.

Private Symbols and Weakmaps are both useful mechanism that are naturally optimized for different use cases.  We wouldn't be making the world simpler by requiring that Weakmaps be used for all those use cases.

I tend to be in the same camp as those who say that they only need non-private Symbols.  But I know that there are significant segments of the developer community who what stronger encapsulation than is offered by reflectable unique symbols.  In particular, I don't see a good way to do strong branding (which the DOM folks demand) using only non-private Symbols. I don't see regular WeakMaps as an viable solution to that problem because of the GC impact.   We could try to introduce a separate per instance mechanism for branding, but then we would have yet another orthogonal feature to integrate (including with Proxies) .  Private symbols, so for,  seems like smallest incremental extension that is a practical solution for the branding use case.

Allen



More information about the es-discuss mailing list