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.@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.@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.@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:he...@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.@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
