new strawman: syntactic support for private names

Axel Rauschmayer axel at
Wed Aug 29 09:53:19 PDT 2012

> 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. at 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]:
> 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.


Dr. Axel Rauschmayer
axel at


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list