shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich brendan at mozilla.org
Sun Jan 22 12:06:28 PST 2012


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:herby at mailbox.sk>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Brendan Eich <mailto:brendan at mozilla.org>
> 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:brendan at mozilla.org>
> January 21, 2012 4:39 PM
>
> Er, const, I hope -- not let. Right?
>
> /be
> Herby Vojčík <mailto:herby at mailbox.sk>
> January 21, 2012 2:21 PM
> Brendan Eich wrote:
>>> Herby Vojčík <mailto:herby at mailbox.sk>
>>> January 21, 2012 1:56 PM
>>> Brendan Eich wrote:
>>>> private foo;
>>>>
>>>> @foo = bar; // this-relative private foo
>>>>
>>>> return @foo === other. at 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:brendan at mozilla.org>
> January 21, 2012 2:11 PM
>> Herby Vojčík <mailto:herby at mailbox.sk>
>> January 21, 2012 1:56 PM
>> Brendan Eich wrote:
>>>> Herby Vojčík <mailto:herby at mailbox.sk>
>>>> 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. at 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
>
>


More information about the es-discuss mailing list