On Aug 28, 2012, at 4:59 PM, Axel Rauschmayer wrote:
> Couldn’t you have the same advantages if:
> - obj.@foo was syntactic sugar for obj[foo]
> - @foo was syntactic sugar for [foo] (method definitions, property
> definitions, etc.)
>
> foo would be a normal variable and the following two statements would be
> equivalent:
> private foo;
> let foo = new Name();
There are been various previous runs at defining syntactic support for using
unique/private names. They all run into either real or hypothetical usability
issues that blocked adoption. One consistent area of concern has been
contextual variation in the use of a sigil such as @. For example:
private member; //(no sigil) user just wants to think of "member" as a
restricted visibility property key.
let obj = {@member: 42}; //they have to remember to use the sigil here
because this is a context where identifiers are implicitly quoted
let fortytwo = obj[member]; //must not use the sigil here
alert(obj.@member); //need to remember to use the sigil here ,
obj.member would meaning something completely different.
In the above scheme, there is nothing that syntactically identifiers a bound
name that is intended to use as a restricted property key. The sigil is a
syntactic element of the usage context. Some contexts require one, others do
not. A user has to mentally track which identifiers hold property keys and and
remember in which contexts a sigil is required or must be avoided.
In my proposal, I attempt to simplify this by making the sigil part of the
actual identifier. At the point of declaration, you decide that a certain
identifier is going to be used to represent a unique name property key. This
decision is reflected in the actual identifier because it must be prefixed with
the @. It is also a immutable binding. It's value is guaranteed to be name
object that was originally associated with it. All subsequent uses of the
identifier must also be prefixed. There is never any confusion about where you
are referring to name object based property name or to a string property name.
You don't have to remember which context are quoting and which are not.
This seems simple, to me.
>
> foo containing a string would also work.
It's not clear that everybody wants this to work. There were objections to it
raised in previous discussions about the computed property names proposal.
The language is arguably simpler if @names are restricted to name object
values. It isn't clear that the use cases for indirecting through a @name to a
string value are important or common enough to justify that additional
conceptual complexity. Finally, attempting to initialize at @name to a none
name object value will throw an error. That leaves open the possibility of a
future extension that allowed them to be initialized to string values.
>
> That would be slightly simpler and go together well with your proposed object
> model reformation [1]:
> https://gist.github.com/3505466
As shown above, I don't think what you are suggest is actually simpler. My
proposal works fine with object model reformation,
obj.@name would do a normal [[Put]]//[Get]] using the name object value of
@name
obj[@name] would do a @elementSet/@elementGet using the name object value of
@name.
Allen
>
> [1] http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
>
> On Aug 29, 2012, at 1:04 , Allen Wirfs-Brock <[email protected]> wrote:
>
>> The strawman is at
>> http://wiki.ecmascript.org/doku.php?id=strawman:syntactic_support_for_private_names
>>
>>
>> Allen
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> --
> Dr. Axel Rauschmayer
> [email protected]
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
