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

Herby Vojčík herby at mailbox.sk
Sat Jan 21 13:33:07 PST 2012


Brendan Eich wrote:
> This was already proposed. See the whole strawman, but in particular
> these sections:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration
>
> http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declaration_scoping
>
> 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).

> We could revive this, but deferring it and simplifying led to
>
> http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects

I was not trying to revive them (not even after reading part of them). I 
was reacting to actual situation, that being: privates should be 
realized through foo. at bar syntax, where bar is identifier (must be 
declared in some scope) and must have name.create() as its value.

Definitely there can be some cases where explicitly creating 
name.value() and playing with it is beneficial, but most of the time 
(imnsho) it's the case that you need to use name.create() just as a key 
in foo. at bar. You should restrict the scope where it is known, and not to 
"export" it, since your "privacy" is gone.

The solution that spring to mind is straightforward the use of 
now-orphaned private keyword for it seems just right. I only proposed 
(as of actual situation, not as revival of old strawman; as a shortcut 
for actual calling name.create() at the start of the program or 
simulated in compilation phase) to use private to declare such 
identifiers, each pre-filled with name.create() once, with block visibility.

For foo. at bar it is very convenient. I really believe big percentage of 
name.create() is of this sort. Not going against 
harmony:private_name_objects, just add a convenient use.

> which is in ES6.
>
> /be

Herby

>> Herby Vojčík <mailto:herby at mailbox.sk>
>> January 20, 2012 3:34 PM
>> Hello,
>>
>> since @-prefixed syntax to access private-named properties seems to
>> win in the private grounds (and it is good thing), I'd like kill two
>> birds with one stone:
>> - private keyword seemed to lose its role
>> - to access property via @foo, I must 'let foo = Name.create()' first
>>
>> So let us allow:
>> ... {
>> private foo, bar;
>> ...
>> agent. at foo = ...;
>> ...
>> more uses of @foo and @bar
>> ...
>> }
>> in imperative (code-containing, semicolon-delimited) blocks and
>> ... {
>> private [foo, bar],
>> ...
>> @foo: Date.now(),
>> @bar: cowboys.length,
>> ...
>> aMethod () {
>> ... use @foo and @bar
>> }
>> }
>> in declarative (data-describing, comma-delimited) blocks.
>>
>> In both cases let it be the declaration of (one-time lexical
>> block-local) private names foo and bar. For any curly block. Without
>> need to define these singletons explicitly and wrap them so they are
>> only visible where due,
>>
>> Herby
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>


More information about the es-discuss mailing list