shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich brendan at mozilla.org
Sun Jan 22 22:29:54 PST 2012


> Allen Wirfs-Brock <mailto:allen at wirfs-brock.com>
> January 22, 2012 4:31 PM
>
> I personally have come to the conclusions that
>
>    obj. at foo
>
> would be a better than
>
>    obj[foo]
>
> for accessing a property of obj that is keyed by the private name that 
> is the value of the foo binding.
>
> My impression, is that a number of other participants in these 
> discussion share this opinion.  These are various reasons for  this 
> preference, including pleasantness, experience from CoffeeScript and a 
> desire (rationalize in 
> http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation ) 
> to strongly distinguish routine structural property access from 
> dynamically computed data key accesses.

If we require only private name objects on the right of @, then there's 
another benefit: no misspelled references to public name where a private 
one is required. @ means private, not computed.
>
> Regardless of whether this proposal flies we could consider supporting:
>
> private foo,bar;
>
> as a short hand for:
>
> //assume already done: import name as "@names";
> const foo=name.create(), bar=name.create();
>
> I think this would be a desirable addition, but I don't want it to be 
> a make or break issue for the .@ proposal.

I'm game. Without it the Name.create() overhead is onerous.

> There are a couple of decision that still need to make for this proposal:
>
> 1) should .@ member access and @ object literal property definitions 
> permit he property key to be any toString-able value and not just 
> private name values?  The current plan of record does not require a 
> private name value in the analogous contexts.
> I'm slightly inclined towards requiring private name values, but would 
> be happy either way.

As noted above, I'm inclined toward requiring private name objects on 
the right of @.
>
> 2)  elimination of arbitrary expression as direct keys in object 
> literal property definitions:
>
> The current "computed property keys" proposals allows things like:
>
> for (var n=0;n<10;) {
>    a.push( {
>       ["prop"+n]: n++
>    });
> }
>
> Do we really need to support this sort of computed property name 
> definition?

Not obviously at this point. We might want [] and @ but we can certainly 
defer [] if we do include @ for private names.

> 3) should @foo as a primary expression be interpreted as this. at foo
>
> I think it should, but note that this means that
>
> const foo = name.create();
> let obj = {
>    @foo: @foo
> };
>
> would mean the same as:
>
> const foo = name.create();
> let obj = {
>    @foo: this. at foo  /key and value probably different values
> };
>
> rather than:
>
> const foo = name.create();
> let obj = {
>    @foo: foo  //key and value are the same value
> };
>
> This might be a source of confusion for some JS programmers.

It's not different from let obj = {foo: foo} which uses foo two 
different ways. We agreed on the shorthand from object destructuring 
being necessary (due to the cover grammar technique we are using -- 
"Supplemental Syntax") and sometimes desirable, e.g.

   function Point(x, y) {
     return {x, y};
   }

So I do not think @foo meaning something different in a property name 
context in an object literal from what it means in an expression is 
either new or necessarily confusing. In both the @ and @-free cases, the 
property name means something different from the expression form.

/be


More information about the es-discuss mailing list