Better eschew [expr]:... and [expr] () {...} because of Object Model Reformation

Herby Vojčík herby at
Wed Dec 5 04:32:19 PST 2012


a year ago I was big fan of [expr] since it was so dynamic, but it 
clashes (visually) with planned Object Model Reformation. OMR is 
probably the higher priority for the future, so I'd suggest let's find 
something else instead of [expr] to make run-time symbols usable.

What I see:

A. Just max-min it.

This does not remove the [expr], but does not put fully-fledged one into 
the language. The proposal is simple: only allow [expr] if expr is 
Identifier. It will allow to use runtime symbols, but will clash 
visually with OMR later.

B. foo.[expr], [expr]:..., [expr] () {...}

This proposes to allow [expr] after dot (where Identifier now is, and 
where @name was just a few days ago as well). Also make .[expr] the new 
low-level construct to access properties programmatically. IOW, instead 
of explaining that is sugar for foo["bar"], now you will explain 
that is sugar for foo.["bar"], and foo["bar"] is _by_default_ 
equivalent to foo.["bar"] but is (planned to be) configurable.

C. (constrained) foo. at pexpr, @pexpr:..., @pexpr () {...}

This is just a variation of B, but with two distinctions:
  - syntax not clashing visually with OMR
  - restrained (not-so-max-minned) at the beginning.
This would propose that one can use @PrimaryExpression after the dot and 
as the name of property/concise method in literals and classes, but this 
PrimaryExpression would be restrained for initial release to Identifier 
or StringLiteral. As B, this should become the new low-level property 
access. It is envisionable that later it can be use with other 
expressions including foo.@("bar"+"baz"). But for now, only Identifier 
(which allow use of symbols) and StringLiteral (to be able to explain 
that is sugar to foo.@"bar".


More information about the es-discuss mailing list