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 <[email protected]> wrote: > Le 17/01/2013 19:30, Mark S. Miller a écrit : > >> On Thu, Jan 17, 2013 at 10:02 AM, David Bruant <[email protected]> >> 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> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
