Herby Vojčík <mailto:[email protected]>
January 21, 2012 1:56 PM
Brendan Eich wrote:
Herby Vojčík <mailto:[email protected]>
January 21, 2012 1:33 PM
Brendan Eich wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declarations_exist_in_a_separate_name_space_parallel_to_the_variable_binding_environment
The last really was too much for some folks. It makes the meaning
of an
identifier after . or before : in an object literal depend on a
binding
declaration, possibly far above.
Thank you. I did not know of these. The problem in the third one (and
the solution) are really crazy... I would do the early error if there
would be a clash (akin to double let).
The way to resolve the two-lexical-binding-chains issue for private
declarations is not to overload . (member expression; also : in object
literals), by requiring @ instead:
private foo;
@foo = bar; // this-relative private foo
return @foo === other.@foo;
return {@foo: bar};
This helps a lot, but there still _is_ (I only proposed a convenient
shortcut, not some magic special names for private names) an
identifier foo having that private name in its value.
This was not decided, as far as I know. There are two choices:
1. "private foo;" defines a lexical binding used to denote the private
name object, as well as after @ to use it to access a property in an object.
2. Rather, the *only* places foo would be allowed after "private foo;"
above are those after an @. IOW it would be fine to use "let foo = 42;"
and "private foo;" without conflict. Some further syntax, a la the old
#.foo proposal (obsoleted in terms of # now), would be required to
reflect foo from lexical-to-the-right-of-@ space into a first-class
private name object reference.
So it _would_ clash if foo was defined in code. But I believe that
this can be solved by applying analogies from let, var, scopes,
shadowing etc. all that machinery.
I'm not sure what you mean. Choice (1) above allows shadowing. Choice
(2) doesn't have any conflict.
I *think* we may be pretty close to consensus on this, but I'm not sure.
Not in ES6 at this point.
Well, I am pretty hoping for this. It makes thing much more
straightforward (when compared to private in actual class proposal
with private store etc. - private names work and are generic).
I may be overoptimistic about consensus. The choice (1) vs. (2) remains
open, IIRC.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
