Tab Atkins Jr. <mailto:[email protected]>
January 22, 2012 11:44 PM
Allow me to be clearer.
Given "foo.bar = new Name();", is "[email protected]" 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.@b
"c"
js> [email protected]()
1
js> [email protected]()
<a b="c"/>
js> x.@b[0]
"c"
js> typeof x.@b[0]
"xml"
js> x.@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 .@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
[email protected]
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
