> 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.
Usability is a good point, people seem to have difficulty with understanding
the reification of property names and this would make it simpler.
>> 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,
The thought is this: If you use [] to access members of a collection (array,
map, etc.) then you’d still have the .@ operator to access properties via
computed names. Long-term, .@ would become the recommended way of doing this.
Axel
--
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
