gbracha / lessRestrictedMixins

Lift some, but not all, of the current restrictions on mixins in Dart.
Apache License 2.0
2 stars 2 forks source link

How to implement this efficiently in dart2js? #4

Open rakudrama opened 9 years ago

rakudrama commented 9 years ago

I'd like to understand how to implement this efficiently when compiled to JavaScript. If possible I'd like to find a solution where

Our experience to date has been that super calls are sufficiently alluring that it is important to make them both compact in the generated code and efficient in dispatch. Ditto mixins.

How should the following program work? Given the usual JavaScript context of

we do not have enough information to determine which mixin application, i.e. which S_dynamic, to use:

class M {
  foo(_) => super.foo(print('M.foo'));
}

class A {
  foo(_) => print('A.foo');
}

class B extends A with M {
  foo(_) => super.foo(print('B.foo'));
}

class C extends B with M {
  foo(_) => super.foo(print('C.foo'));
}

main() {
  new C().foo();
}

If we can somehow avoid the above problem (e.g. making it an error to mix in the same class twice), then M.foo's call to super.foo could be implemented as this.from$M$foo$1(...) with each S_dynamic defining from$M$foo$1 as an alias to the appropriate method (i.e. a separate property in a prototype chain object that has the same value as the main property).

gbracha commented 9 years ago

Banning repeated mixins occurred to me as well. It's distasteful, but seems relatively harmless (he says carelessly ...). However, once you add mixin composition (which people are already agitating for) it becomes more of concern, as it violates encapsulation.

One could choose to a rewrite only if a mixin was repeated (in fact, only if the mixin was repeated and had super calls). This would occur quite rarely, so the extra space wouldn't be as much of an issue.