Split out Index AST node from Invoke

Split out Index AST node from Invoke

BUG=
R=jmesserly@google.com

Committed: https://code.google.com/p/dart/source/detail?r=30437

[justinfagnani, 2013-11-16 02:39:57]

Doesn't move the perf needle, but a good cleanup. I'll split property/getter
access next

[Jennifer Messerly, 2013-11-18 20:28:41]

lgtm

https://codereview.chromium.org/74543003/diff/40001/pkg/polymer_expressions/b...
File pkg/polymer_expressions/benchmark/eval.dart (right):

https://codereview.chromium.org/74543003/diff/40001/pkg/polymer_expressions/b...
pkg/polymer_expressions/benchmark/eval.dart:34: var score = new
EvalBenchmark(name, expr, model: model, variables: variables).measure();
long line

https://codereview.chromium.org/74543003/diff/40001/pkg/polymer_expressions/l...
File pkg/polymer_expressions/lib/eval.dart (right):

https://codereview.chromium.org/74543003/diff/40001/pkg/polymer_expressions/l...
pkg/polymer_expressions/lib/eval.dart:85: * literal index.
out of curiosity, why have the restriction that the index must be literal? is it
just not implemented?

[justinfagnani, 2013-11-20 02:23:16]

On 2013/11/18 20:28:41, John Messerly wrote:
> lgtm
> 
>
https://codereview.chromium.org/74543003/diff/40001/pkg/polymer_expressions/b...
> File pkg/polymer_expressions/benchmark/eval.dart (right):
> 
>
https://codereview.chromium.org/74543003/diff/40001/pkg/polymer_expressions/b...
> pkg/polymer_expressions/benchmark/eval.dart:34: var score = new
> EvalBenchmark(name, expr, model: model, variables: variables).measure();
> long line
> 
>
https://codereview.chromium.org/74543003/diff/40001/pkg/polymer_expressions/l...
> File pkg/polymer_expressions/lib/eval.dart (right):
> 
>
https://codereview.chromium.org/74543003/diff/40001/pkg/polymer_expressions/l...
> pkg/polymer_expressions/lib/eval.dart:85: * literal index.
> out of curiosity, why have the restriction that the index must be literal? is
it
> just not implemented?

[justinfagnani, 2013-11-20 03:47:10]

Committed patchset #2 manually as r30437 (presubmit successful).

[justinfagnani, 2013-11-20 03:50:33]

https://chromiumcodereview.appspot.com/74543003/diff/40001/pkg/polymer_expres...
File pkg/polymer_expressions/benchmark/eval.dart (right):

https://chromiumcodereview.appspot.com/74543003/diff/40001/pkg/polymer_expres...
pkg/polymer_expressions/benchmark/eval.dart:34: var score = new
EvalBenchmark(name, expr, model: model, variables: variables).measure();
On 2013/11/18 20:28:41, John Messerly wrote:
> long line

Done.

https://chromiumcodereview.appspot.com/74543003/diff/40001/pkg/polymer_expres...
File pkg/polymer_expressions/lib/eval.dart (right):

https://chromiumcodereview.appspot.com/74543003/diff/40001/pkg/polymer_expres...
pkg/polymer_expressions/lib/eval.dart:85: * literal index.
On 2013/11/18 20:28:41, John Messerly wrote:
> out of curiosity, why have the restriction that the index must be literal? is
it
> just not implemented?

No, I was just being conservative at the time and wanted to make sure that we
knew which object we were assigning too. Some cases, like f(a) and (a + 2) are
clearly not assignable, while f(a).name might be. This simplest restriction I
could come up with property paths, but supporting a.b[3].c seemed very useful
not far from property paths. The more general restriction is that we need to be
able to separate the expression into the owner and the property and right not
the property must be a name or constant index value. We can relax this so that
the property can be an expression that's evaluated and then as long as we can
separate the expression, it's assignable. f(a) still wouldn't work, but
f(a).name would, and a[b].

[Jennifer Messerly, 2013-11-20 04:04:55]

https://chromiumcodereview.appspot.com/74543003/diff/40001/pkg/polymer_expres...
File pkg/polymer_expressions/lib/eval.dart (right):

https://chromiumcodereview.appspot.com/74543003/diff/40001/pkg/polymer_expres...
pkg/polymer_expressions/lib/eval.dart:85: * literal index.
On 2013/11/20 03:50:33, justinfagnani wrote:
> On 2013/11/18 20:28:41, John Messerly wrote:
> > out of curiosity, why have the restriction that the index must be literal?
is
> it
> > just not implemented?
> 
> No, I was just being conservative at the time and wanted to make sure that we
> knew which object we were assigning too. Some cases, like f(a) and (a + 2) are
> clearly not assignable, while f(a).name might be. This simplest restriction I
> could come up with property paths, but supporting a.b[3].c seemed very useful
> not far from property paths. The more general restriction is that we need to
be
> able to separate the expression into the owner and the property and right not
> the property must be a name or constant index value. We can relax this so that
> the property can be an expression that's evaluated and then as long as we can
> separate the expression, it's assignable. f(a) still wouldn't work, but
> f(a).name would, and a[b].

makes sense. yeah, I think we'd eventually want all lvalues to be supported,
where lvalue is either:

name  (variable)
expr.name (property access)
expr[expr] (indexing)