New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable mixin a @JS class #28260

Closed
dam0vm3nt opened this Issue Jan 5, 2017 · 4 comments

Comments

Projects
None yet
6 participants
@dam0vm3nt
Copy link

dam0vm3nt commented Jan 5, 2017

It would be nice if package:js could allow mixin a @JS annotated class and have DDC produce the usual ES6 code for mixins :

dart:

@JS()
class MyBehavior {
  external get thing;
}

@JS()
class Something {
}

class MyType extends Something with MyBehavior {
}

ES6

class MyType extends MyBehavior(dart.global.Something) {
  ....
}
@jacob314

This comment has been minimized.

Copy link
Member

jacob314 commented Jan 10, 2017

How valuable is this feature? I don't see how we would support it in dart2js or dartium so it is a bit of a harder sell for DDC.

@dam0vm3nt

This comment has been minimized.

Copy link
Author

dam0vm3nt commented Jan 10, 2017

My opinion is that this is coherent with one of the DDC targets : to produce a more idiomatic js code. So as dart classes get translated into es6 classes so should dart mixin. At least when interoperating with js code.

Another reason is that it makes more simple to interopetate with es6 framework like for example polymer.

As for the differences between DDC and dart2js I think that they already produce different code so this should not be an issue as long as semantic is preserved.

@Edited

@dam0vm3nt

This comment has been minimized.

Copy link
Author

dam0vm3nt commented Jan 11, 2017

On the other side I have to admit that there's no such a thing like "ES6 mixin". That's only a "code convention". But there are reasons to think that that's the closest aproximation to a mixin in ES6, see for example here.

To apply this approach only to @JS annotated classes used as mixin should not be a big problem, while extending such approach to native dart mixin indeed is more complicated.

1 . How would you dedide that a class is worth behaving as a mixin and thus translate it in a different way ?
2. Should a class elected to become a possible mixin be translated in two different ways ?

For point 1 I think there's already a logic that check if a class can be used as mixin, in the analyzer for sure.

For point 2 a "mixable" class could be translated in the following way:

Dart version

class MyDartMixin {
   String prop;
   String method(String x) {
       ...
    }
}

Translated ES6

MyDartMixin_asMixin = (otherclass) => class _MyDartMixin extends otherclass {
   _MyDartMixin() {
           super();
          new();
   }
   
   new() {
       this.prop=null;
   }

  method(x) {
     ...
  }

}

MyDartMixin = MyDartMixin_asMixin(Object)

And obviously one should check if using this approach or similar is semantically equivalent to the previous one.

@matanlurey

This comment has been minimized.

Copy link
Contributor

matanlurey commented Jun 19, 2018

I think its unlikely this will happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment