I suspect your very complicated translation with __prvTable__ etc. is
intended to hoist private somehow, once per declaration in source rather
than once per evaluation of declaration. That's too restrictive, since
private declarations can be placed in outer blocks or closures for
singleton naming, or moved into inner constructor-like functions for
per-instance private names.
Users should be able to declare class-private and instance-private
names, in other words.
Your block examples, which I modified, are not complete enough to judge
what's wanted. By asserting singleton private name per source
declaration you are deciding prematurely and overconstraining the
feature. Let the user put the block or closure at the right inner or
outer level and declare there. There are an arbitrary number of
generative layers (generations): class static private, class instance
private, inner closure private, etc. etc.
/be
Herby Vojčík <mailto:[email protected]>
January 22, 2012 10:16 AM
Brendan Eich wrote:
And _the_real_foo should be expanded:
{
private foo;
...
}
desugars to
{
const foo = Name.create("foo");
BTW, would this not mean it is different in every run?
...
}
with Name.create imported appropriately.
/be
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich <mailto:[email protected]>
January 21, 2012 4:41 PM
And _the_real_foo should be expanded:
{
private foo;
...
}
desugars to
{
const foo = Name.create("foo");
...
}
with Name.create imported appropriately.
/be
Brendan Eich <mailto:[email protected]>
January 21, 2012 4:39 PM
Er, const, I hope -- not let. Right?
/be
Herby Vojčík <mailto:[email protected]>
January 21, 2012 2:21 PM
Brendan Eich wrote:
Herby Vojčík <mailto:[email protected]>
January 21, 2012 1:56 PM
Brendan Eich wrote:
private foo;
@foo = bar; // this-relative private foo
return @foo === other.@foo;
return {@foo: bar};
This helps a lot, but there still _is_ 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.
Oh. I favor 1. Inspired by latest notes and for(let...) I would see
{
private foo;
...
}
desugared to
{
let foo = _the_real_foo;
...
}
where _the_real_foo is defined somewhere at the module or program
level such that it will not clash (hardwired private name or index to
a table or whatever) and the rest is just reusing existing rules.
2. is too magical (for me).
/be
Herby
Brendan Eich <mailto:[email protected]>
January 21, 2012 2:11 PM
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
