Le 17/01/2013 18:00, Mark S. Miller a écrit :
However, after the "Private Slots" thread, I spent a sleepless night
chewing on getting rid of private symbols.
Happens to me so often :-)
I now think we should.
Going back to my earlier
On Wed, Jan 16, 2013 at 12:37 PM, Mark S. Miller <[email protected]> wrote:
My position on private symbols.
My position on classes is and has always been that classes are worth
introducing into the language *only* if they give us, or can be used
with, an affordable means for true object encapsulation. Assuming
Allen is right about what actual implementors will do (which I find
plausible) then WeakMaps are not that means.
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.
Now you're only talking about privacy in the context of classes in this
post. I understand this as assuming private symbols would be only use in
class or class-like contexts (after referred as "this assumption" or
"the assumption").
If that's your assumption, then I agree that if classes have a "private"
syntax that is efficiently compiled, private symbols can be dropped.
It has to be noted that if private symbols are dropped, the set of
private properties is sealed once and for all in the class body. That
is, it's not possible to add or remove a private property after
initialization. (However it remains possible to privately attach
information to an object with a weakmap kept private)
If "private symbols will be only used in class or class-like contexts"
is your assumption, let's talk about it. Historically, JavaScript
objects have been used in both in OO contexts and as maps. This
confusion led to some bugs (involving __proto__ for instance)
As I have suggested in another recent post, most of the time, objects in
OO contexts are pretty stable: they are created with a given set of
properties which doesn't change. This stability could even be declared
statically (that's what the class syntax does actually).
However, for the map use case, it makes sense to add and remove
properties at runtime.
ES6 adds actual maps, so objects (especially the ones instanciated after
class-born constructors) could be legitimately considered as reserved
for OO contexts.
That's a reasoning I agree with since I can't think of cases besides
classes where private symbols would be used and for which weakmaps
wouldn't be better.
So I guess I agree with the removal of private symbols given classes
have a syntax for private properties and no other relevant use case for
private symbols is found.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
