Initializes _data in constructor

Now initializing _data in constructor

.. rather than initializing a cache for it lazily and repeatedly
checking whether the cache has been initialized.

[eernst, 2015-08-18 10:27:55]

eernst@google.com changed reviewers:
+ floitsch@google.com

[eernst, 2015-08-18 10:27:55]

Changes the treatment of data[_reflector] in several types of mirrors such that
it is computed once during construction rather than being initialized lazily and
cached.

Is a followup on https://codereview.chromium.org/1289933004.

[sigurdm, 2015-08-18 10:36:10]

sigurdm@google.com changed reviewers:
+ sigurdm@google.com

[sigurdm, 2015-08-18 10:36:10]

lgtm

[eernst, 2015-08-18 11:25:37]

Unfortunately, the code generated as `"r.data = ${code};"` now makes an attempt
to access `r.data` during the evaluation of the value of `${code}` (because
there are circularities in the object structure involving `r.data`). We could
work around this difficulty using a lazily evaluated element somewhere along
each of these cyclic structures, but that is exactly what the `_data` getter
used to do. So we'd end up with no improvements in speed (because we'll use
`r.data` as the cycle-breaker), or a considerably more complex setup (because we
use something else as the cycle-breaker, hoping that that other thing would get
accessed much less frequently).

So I'd recommend that we do not try to eliminate the lazy access to `_data`
after all, and forget all about this CL.

[eernst, 2015-08-18 11:27:13]

This experiment shows why we cannot easily eliminate the lazy initialization of
`_data` in certain mirrors after all: Let's just drop this CL and keep the lazy
initialization.

[floitsch, 2015-08-18 12:10:58]

On 2015/08/18 11:27:13, eernst wrote:
> This experiment shows why we cannot easily eliminate the lazy initialization
of
> `_data` in certain mirrors after all: Let's just drop this CL and keep the
lazy
> initialization.

too bad.