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

[Brendan Eich]

> Tab Atkins Jr. <mailto:jackalmage at gmail.com>
> January 22, 2012 11:44 PM
>
> Allow me to be clearer.
>
> Given "foo.bar = new Name();", is "baz. at foo.bar" equivalent to
> "baz[foo.bar]" 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)

   baz.(@foo).bar

not

   baz.(@foo.bar)

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
"c"
js> x. at b.length()
1
js> x. at b.parent()
<a b="c"/>
js> x. at b[0]
"c"
js> typeof x. at b[0]
"xml"
js> x. at b[0].nodeKind()
"attribute"


> 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[foo.bar]" form and the
> "{[foo.bar]: 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[foo.bar] expression can be written in any event, whether 
foo.bar 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 foo.bar -- one can (currently, see closing 
below for more) use [].

2. The {[foo.bar]: ...} 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 @:

   baz.@(foo.bar)

would obviously differ from

   baz. at foo.bar

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

The wrinkle here is future-proofing against

http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation

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

/be