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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
