Security Demands Simplicity (was: Private Slots)

Brendan Eich brendan at
Sun Jan 20 12:49:10 PST 2013

David Bruant wrote:
> Le 20/01/2013 19:01, Brendan Eich a écrit :
>> David Bruant wrote:
>>> Once again, the spec (well... you in that case :-) ) will do 
>>> whatever is necessary to make the feature understandable by spec 
>>> readers.
>>> Transpilers will work with whatever is in the language. If they only 
>>> have weakmaps, they'll use that. 
>> See, in 
>> particular
>>    Means
>> 1.
>>    Minimize the additional semantic state needed beyond ES5.
>> 2.
>>    Provide syntactic conveniences for:
>>     1.
>>        good abstraction patterns;
>>     2.
>>        high integrity patterns;
>>     3.
>>        defined by desugaring into kernel semantics.
>> We aim to unify the "spec problem" and the "transpiler problem" where 
>> possible.
> I think the goal of providing syntactic conveniences defined by 
> desugaring into kernel semantics is a valuable goal. It's good to 
> reason about this semantics and it's good for transpilers.
> I however disagree that it should be taken to the letter as Allen 
> seems to take it. Specifically, I disagree with the idea that all 
> kernal semantics should be exposed as runtime constructs. They should 
> only if they prove to be useful for some other purpose.

Hence my "where possible".

Note the Reference internal type among others.

Please do try to avoid casting positions as absolute when they 
explicitly are not.

>> Not always, not necessarily by spec-by-desugaring.
>> But we don't want magic in the spec that leaves transpilers falling 
>> into the tarpit, if we can avoid it.
> Semantics of private-class syntax hasn't been agreed on, so it's hard 
> to say if transpilers would have a hard time with the 
> eventually-agreed semantics, but Mark's desugaring with WeakMaps could 
> work, couldn't it?

Do we want protected? Do we have an issue (Kevin is getting at this) 
with proxies observing that private-in-class is based on something other 
than properties named by private symbols?

If proxies can observe that, yes, you are right: we may still use 
internal spec types to specify private-in-class. But we should also 
consider using weak maps and supporting transpilers, and committing to 
any observables.

Doing so closes the door to private symbols in the future, in my view.


More information about the es-discuss mailing list