compute interfaces lazily

compute interfaces lazily
otherwise we'd have to make a lot more classes lazy

R=jacobr@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/e8f1f8fc8d4ebdb170d7f9fa5ab33d138313c4ef

[Jennifer Messerly, 2015-03-31 16:04:40]

jmesserly@google.com changed reviewers:
+ jacobr@google.com, vsm@google.com

[Jennifer Messerly, 2015-03-31 16:04:40]

This seems like the simplest fix.

@vsm and I were discussing yesterday another way of doing this:

   class RegExp extends Object {
+    static get [dart.implements]() {
+      return [Pattern];
+    }
     RegExp(source, opts) ...
   }

assuming I could get it to be one line, would this be preferred:

   class RegExp extends Object {
+    static get [dart.implements]() { return [Pattern]; }
     RegExp(source, opts) ...
   }

the keywords make it a bit noisy but it could work. We could even do:

   class RegExp extends Object {
+    [dart.implements]() { return Pattern; }
     RegExp(source, opts) ...
   }

while that's an instance method, we could query it via
RegExp.prototype[dart.implements]()

On a similar brainstorming note, we could actually defer mixins until an
instance is created, too:

-  class ListBase extends dart.mixin(core.Object, ListMixin$(E)) {
+  class ListBase extends dart.mixin(core.Object) {
+    [dart.with]() { return ListMixin$(E); }

thoughts?

[Jennifer Messerly, 2015-03-31 16:07:37]

by the way, here was the alternative that emits interfaces first:
https://codereview.chromium.org/1045323002/

what I didn't like is it increased the number of defineLazyClass calls in the
core libs rather dramatically, from 5 to 54. Some of that I might be able to fix
by tweaking the import ordering, but seems bad to add more things that need to
be ordered across library cycles.

[Jacob, 2015-03-31 16:10:29]

lgtm

[Jennifer Messerly, 2015-03-31 16:10:36]

On 2015/03/31 16:07:37, John Messerly wrote:
> by the way, here was the alternative that emits interfaces first:
> https://codereview.chromium.org/1045323002/
> 
> what I didn't like is it increased the number of defineLazyClass calls in the
> core libs rather dramatically, from 5 to 54. Some of that I might be able to
fix
> by tweaking the import ordering, but seems bad to add more things that need to
> be ordered across library cycles.

actually it does look like the ordering is fixable. Let me get updated stats for
that approach.

[Jennifer Messerly, 2015-03-31 16:14:41]

Committed patchset #1 (id:1) manually as
e8f1f8fc8d4ebdb170d7f9fa5ab33d138313c4ef (presubmit successful).

[vsm, 2015-03-31 17:15:48]

lgtm