List literals in polymer_expressions

List literals in polymer_expressions

BUG=
R=jmesserly@google.com

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

[justinfagnani, 2014-01-27 19:11:46]

Fixes https://code.google.com/p/dart/issues/detail?id=16334

[Jennifer Messerly, 2014-01-28 00:07:04]

lgtm

https://codereview.chromium.org/139903008/diff/1/pkg/polymer_expressions/lib/...
File pkg/polymer_expressions/lib/eval.dart (right):

https://codereview.chromium.org/139903008/diff/1/pkg/polymer_expressions/lib/...
pkg/polymer_expressions/lib/eval.dart:342: items.forEach((e) => e._parent =
list);
thought for future refactoring ... it might be more consistent to move the
_parent logic to the constructor for the various types. That way the correct
parent relationship is guaranteed after construction.

I wouldn't do it in this CL though since it would affect all of the visit*
methods :)

[justinfagnani, 2014-01-28 02:16:21]

https://codereview.chromium.org/139903008/diff/1/pkg/polymer_expressions/lib/...
File pkg/polymer_expressions/lib/eval.dart (right):

https://codereview.chromium.org/139903008/diff/1/pkg/polymer_expressions/lib/...
pkg/polymer_expressions/lib/eval.dart:342: items.forEach((e) => e._parent =
list);
On 2014/01/28 00:07:04, John Messerly wrote:
> thought for future refactoring ... it might be more consistent to move the
> _parent logic to the constructor for the various types. That way the correct
> parent relationship is guaranteed after construction.
> 
> I wouldn't do it in this CL though since it would affect all of the visit*
> methods :)

Agreed. I actually want to get rid of the observer wrappers all together, which
I think would force this to happen.

[justinfagnani, 2014-01-28 02:17:04]

Committed patchset #1 manually as r32049 (presubmit successful).