Hi Maciej,
Le 08/01/2014 09:59, Maciej Jaros a écrit :
To my understanding private name objects
Note that now their name is "symbol" and not "private name" anymore.
are supposed to make private properties and functions available for
new classes syntax in ECMAScript 6 standard.
A "private" keyword will be introduced in ES7. There is still
disagreement on the specifics of the semantics.
But the syntax is rather strange:
```
var myPrivate = new Name();
class Test {
constructor(foo) {
this[myPrivate] = foo;
}
}
```
I understand the motivation - using just `this[myPrivate]` wouldn't
work because it could be inconsisten when `myPrivate` is a string
variable. If `myPrivate='abc'` then `this[myPrivate]` is equivalent
`this.abc`... So that is the main reason Name objects were born, right?
For the sake of making your code easier to write, read and understand,
you wouldn't reassign "myPrivate", preferably even declare it with
"const" instead of "var".
BUT what is the point of having this new syntax if I need to predefine
all private variables (also the ones used for methods)?
It's a temporary setup. A "private" keyword will be introduce and
provide runtime-level privacy (as opposed to source-level privacy like
TypeScript does)
Instead of above I could just use (shorter, more intuitive, already
works):
```
var myPrivate;
class Test {
constructor(foo) {
myPrivate = foo;
}
}
```
I could also secure the scope which would still be shorter for more
then one variable:
```
(function(){
var myPrivate, myPrivate2;
class Test {
constructor(foo) {
myPrivate = foo;
myPrivate2 = foo.toString();
}
}
})()
```
Does it really already works? It looks to me like your private variables
are shared by all instances (while private in class is supposed to be
per instance). When the constructor is called twice, only the last
values will remain.
I'm probably missing some optimization points but I was unable to find
them on ES Wiki.
I believe the wiki is outdated. [1] has a message at the top saying:
"This proposal has progressed to the Draft ECMAScript 6 Specification,
which is available for review here: specification_drafts. Any new issues
relating to them should be filed as bugs at http://bugs.ecmascript.org.
The content on this page is for historic record only and may no longer
reflect the current state of the feature described within."
The only new thing is the Name object. I see no use case for it and it
doesn't seem to be more readable then current solution.
Per-instance runtime-level privacy. JavaScript lacks this badly. Note
that I didn't mention classes. We need privacy even beyond the context
of classes.
It's possible to achieve it with WeakMap with something along the lines of:
````js
var privateState = new WeakMap();
function createPrivateState(o){
privateState.set(o, {});
}
function _private(o){ // "private" is a reserved keyword
return privateState.get(o);
}
class C{
constructor(yo){
createPrivateState(this);
_private(this).yo = yo;
}
getYoPlusTwo(){
return _private(this).yo+2;
}
}
````
But performance are certainly attrocious because of the WeakMap lookup
by comparison to what it could be if the property was a string or symbol.
What I'm saying is - please consider dropping `Name` objects and use
some new syntax (e.g. `this#variable`) to avoid clashes but make
declarations more readable for humans.
I can't speak for TC39, but from what I see and read, they're not going
to drop symbols.
Note that regarding privacy, there is the "relationship" strawman on the
table IIRC
http://wiki.ecmascript.org/doku.php?id=strawman:relationships
I've lost track of what the state of that is.
Last thing I have found [2]:
"Sam, Mark and Allen to work on "relationships" and varied
representation in ES6."
David
[1]
http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes
[2]
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-03/mar-13.md#conclusionresolution-1
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
