Test for constructor order and bindings.

Test for constructor order and bindings.

BUG=
TEST=

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

[sra1, 2011-11-01 23:39:38]

Hi Gilad,

Please can you verify these test cases reflect the desired semantics?


These tests derive from my concern about the interaction of the
following statements in the specification:

  "Then, the constructor's initializers are executed in the order they
  appear in the program."

and

  "Execution of the body begins with execution of the body of the
  superconstructor with respect to the bindings determined by the
  argument list of the superinitializer of k."

Since the superconstructor-initializers and superconstructor-body can
be executed with other initializers interposed (e.g. b2 in the tests)
it is not obvious how the bindings can be remembered over the interval.

I can think of several implementation strategies.  All seem somewhat
cumbersome, and when translated to JavaScript would look unlike a
natural translation.

The first is to inline the entire superconstructor chain, so that the
binding is compiled to a single variable.  This is an onerous
requirement for a naive compiler, and potentially inefficient if a
common superclass has an enormous constructor body.

The second strategy is to package all initializers that follow the
superconstructor-initializer call into a thunk, and pass that thunk to
a merged superconstructor-initializer+superconstructor-body.  A naive
compiler would always have the unwanted overhead of calling this
'middle-continuation', even though it would often be a no-op.

A third strategy is to convert modified parameters into some kind of
cell, rewriting all accesses to be get and set operations on the cell.
It is not clear how to arrange that the correct sets of reified locations
are shared between the initializer and body, but at least they can be aliases.

[gbracha, 2011-11-02 00:08:05]

Did I mention I wanted parameters to be implicitly final ... oh well, I lost
that argument.

Anyway, except for 21 vs. 22 it looks good. I would be sympathetic to a language
change that said the super call has to be the last initializer.

http://codereview.chromium.org/8440015/diff/2001/tests/language/src/Construct...
File tests/language/src/Constructor5Test.dart (right):

http://codereview.chromium.org/8440015/diff/2001/tests/language/src/Construct...
tests/language/src/Constructor5Test.dart:49:
Expect.equals("10-100-50-20-101-51-11-22-", trace);
why is it 22 instead of  21?

[hausner, 2011-11-02 00:09:27]

The second test is quite mean :) I think you read the spec right.

I have a change out for review that implements the (hopefully) correct
evaluation order in the VM. I am evaluating the super initializer argument
expressions and save them in a temporary variable which is then passed to the
super initializer and the block of the super constructor.

http://codereview.chromium.org/8440015/diff/2001/tests/language/src/Construct...
File tests/language/src/Constructor6Test.dart (right):

http://codereview.chromium.org/8440015/diff/2001/tests/language/src/Construct...
tests/language/src/Constructor6Test.dart:25: var r2 = f();   // .. the effect of
+=100 will be seen here.
You probably want to compare r1 and r2, to make sure the modified arg is
reflected.

[srdjan, 2011-11-17 22:16:54]

http://codereview.chromium.org/8440015/diff/1002/tests/language/language.status
File tests/language/language.status (right):

http://codereview.chromium.org/8440015/diff/1002/tests/language/language.stat...
tests/language/language.status:37: Constructor5Test: Fail          # Bug 8440015
This bug number is incorrect.

http://codereview.chromium.org/8440015/diff/1002/tests/language/language.stat...
tests/language/language.status:125: Constructor6Test: Fail       # Issue 8440015
+ 'super' initializer does not parse
ditto

[gbracha, 2011-11-17 22:29:52]

lgtm

[jimhug, 2011-11-18 17:43:36]

lgtm

However, I really hope that the ultimate answer here is to simplify the spec and
thus all Dart implementations here.