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

Brendan Eich brendan at
Mon Jan 23 00:04:40 PST 2012

> Tab Atkins Jr. <mailto:jackalmage at>
> January 22, 2012 11:44 PM
> Allow me to be clearer.
> Given " = new Name();", is "baz. at" equivalent to
> "baz[]" or "baz[foo].bar"?

There's no requirement that @ be lower precedence than a later dot. The 
abstract syntax is the same as (if parentheses were allowed)




BTW, there's precedent for .@ in E4X (ECMA-357) and the grammar is the 
same, although the semantics are to access XML attributes:

js> x = <a b="c"/>
<a b="c"/>
js> x. at b
js> x. at b.length()
js> x. at b.parent()
<a b="c"/>
js> x. at b[0]
js> typeof x. at b[0]
js> x. at b[0].nodeKind()

> Normal property-access semantics
> would give the latter.

Would give baz[foo].bar where foo = 'foo', you mean? Yes, that's true.

> If so, then we need to preserve the [] form
> for use with private names in both the "baz[]" form and the
> "{[]: true}" form, unless we find it acceptable for authors to
> be forced to use a local variable to store the Name every time.

Let's split the cases:

1. The baz[] expression can be written in any event, whether denotes a private name object or any other value (which is 
ToString'ed). There is no requirement to use a temporary to address such 
a private-named property -- [] works already and we aren't removing it.

Turning this around, just because . at foo works (no dot binding tighter 
than @) does not mean there's no alternative other than to use a temp if 
the private name is denoted -- one can (currently, see closing 
below for more) use [].

2. The {[]: ...} object literal case is out of luck, but not 
because of @ binding tighter than dot -- we already do not support any 
kind of computed property name here. If we want one, we should consider 
[] syntax in the property name context in object literals.

Of course, we could elaborate @ to allow a parenthesized expression as 
its operand, so you could make the abstract syntax I sketched above 
concrete, with the ( after the @:


would obviously differ from

   baz. at

But this seems unnecessary in view of the existing [] operator (1 above).

The wrinkle here is future-proofing against

which has not yet achieved consensus in TC39. Once baz[] might 
diverge from meaning property access, one could imagine needing 
baz.@( I'd rather cross that bridge if we come to it.


More information about the es-discuss mailing list