new strawman: syntactic support for private names

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Aug 29 09:39:48 PDT 2012


On Aug 28, 2012, at 4:59 PM, Axel Rauschmayer wrote:

> Couldn’t you have the same advantages if:
> - obj. at 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. 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.

> 
> 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. at 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 <allen at wirfs-brock.com> wrote:
> 
>> The strawman is at http://wiki.ecmascript.org/doku.php?id=strawman:syntactic_support_for_private_names 
>> 
>> Allen
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> -- 
> Dr. Axel Rauschmayer
> axel at rauschma.de
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120829/903640f9/attachment-0001.html>


More information about the es-discuss mailing list