Security Demands Simplicity (was: Private Slots)

Brandon Benvie brandon at brandonbenvie.com
Thu Jan 17 13:50:53 PST 2013


November's meeting had re-instituted computed property names to compensate
for the dropping @name support to allow for symbols to be used as method
names. AFAICT there's currently no actual way to create a private Symbol in
any active proposals for ES6, however (this was only covered as part of the
@names proposal). Currently `Symbol` only accepts one parameter, and that's
the string label/name for it.


On Thu, Jan 17, 2013 at 4:13 PM, David Bruant <bruant.d at gmail.com> wrote:

> Le 17/01/2013 19:30, Mark S. Miller a écrit :
>
>> On Thu, Jan 17, 2013 at 10:02 AM, David Bruant <bruant.d at gmail.com>
>> wrote:
>>
>>> Le 17/01/2013 18:00, Mark S. Miller a écrit :
>>>
>>>> I still have this position on classes. But I no longer buy that
>>>>
>>>> pessimistic conclusion about WeakMaps. Consider how WeakMaps would be
>>>> used by the expansion of classes-with-private. Just 'cause it's on the
>>>> top of my head, below I use the old representation of one WeakMap per
>>>> class providing access to a record of all the private state. For the
>>>> same reason, I'll use the encapsulation of the Purse example without
>>>> any of the numeric checks.
>>>>
>>>> class Purse {
>>>>       constructor(private balance) {
>>>>       getBalance() { return balance; }
>>>>       makePurse() { return Purse(0); }
>>>>       deposit(amount, srcPurse) {
>>>>           private(srcPurse).balance -= amount;
>>>>           balance += amount;
>>>>       }
>>>> }
>>>>
>>>> expansion
>>>>
>>> I don't understand the need to expand. This is the class syntax. It
>>> creates
>>> a constructor. Instances of this constructor have some behavior and
>>> characteristics described by the class body. If the class body allows to
>>> define something private, implementors will implement that and work very
>>> hard on performance. I don't think implementors will expand before
>>> compiling
>>> and using the class syntax as some sort of macro (implementors are free
>>> to
>>> tell I'm wrong here).
>>> Assuming I'm right, what it expands to exactly does not matter much,
>>> whether
>>> it's private name or weakmaps or whatever else.
>>>
>> Regarding what I actually said, you're right. I am being unbelievable
>> confusing this morning. After that sleepless night, I should probably
>> wait till I'm rested before posting again. Foolishly perhaps, I'll try
>> to answer anyway.
>>
>>
>> 1) It remains useful to define the semantics of classes by expansion.
>> Then one can reason about classes by reasoning about the expansion.
>> This is especially helpful for automated tools. The semantics had then
>> better be faithful to the explanatory expansion.
>>
>> 2) Until ES7 provides private
>>
> I may have missed something. In the harmony proposal on the wiki [1] (is
> the wiki down? I'm looking at google's cache), I see that syntax for
> private properties is in the proposal and nothing suggests it's postpone
> until ES7. I see in recent notes that the @-syntax isn't fully agreed upon,
> but that's where I'm at. Is there no private syntax at all for classes in
> ES6?
>
>
>  there will be transpilers that provide actual privacy by other means.
>>
> What syntax and semantics will these transpilers use if TC39 doesn't reach
> an agreement?
>
>
>  3) Most important, and most unsaid by my previous email: In ES6, since
>> there's no built-in class/object privacy mechanism, ES6 programmers in
>> general and ES6 class programmers specifically have to achieve real
>> privacy by other means -- by engaging in some pattern using other
>> constructs. Previous conversations assumed that these patterns would
>> be expressed in terms of private symbols. Absent private symbols, the
>> pattern shown by my expansion above, as painful as it is, is what will
>> be expressed manually. By the time ES7 rolls out, there will be a lot
>> of that code.
>>
> People who care will use a transpiler (and I personally don't care if the
> generated code is slightly slower than what it could be natively or ugly).
> People who don't care about privacy will go on with their lives writing
> JavaScript as they do in ES5.
> That's an ephemeral problem in my opinion and isn't the "most important"
> point. Am I underestimating it?
>
> David
>
> [1] http://wiki.ecmascript.org/**doku.php?id=harmony:classes<http://wiki.ecmascript.org/doku.php?id=harmony:classes>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130117/04201b14/attachment.html>


More information about the es-discuss mailing list