Language: Mixin composition

[DartBot]

_This issue was originally filed by @simonpai_

---

Currently Dart does not support direct mixin composition as mentioned in the document (http://www.dartlang.org/articles/mixins/). However if we have a way to either define M1 * M2 or just make

class X extends Object with A, B {
   ...
}
typedef Y = Object with A, B;

X, Y valid mixin candidates, it will come in very handy to build flexible class plugins.

Algebraically there is no loophole to define the composition operator, and the association will work perfectly.

Related issue:
http://www.dartbug.com/8127

[DartBot]

_This comment was originally written by @simonpai_

---

link to discussion:
https://groups.google.com/a/dartlang.org/forum/?fromgroups=#!topic/misc/0rUZ3eNwyQc

[gbracha]

Yes, mixin composition is a useful notion and it would be nice to have it. It won't happen in the first release though.

---

_Set owner to @gbracha._
_Added this to the Later milestone._
_Added Area-Language, Accepted labels._

[kasperl]

_Removed this from the Later milestone._
_Added Oldschool-Milestone-Later label._

[kasperl]

_Removed Oldschool-Milestone-Later label._

[lrhn]

It would be great if we could have it (say for version 2.0, whenever that comes), since it - along with removing some of the restrictions - would allow the libraries to use mixins in a more consistent and usable manner.

Currently, in order to have a proper ListMixin that is usable by itself, we have to copy (textually) the implementation of IterableMixin, because otherwise the user would have to know to extend with both IterableMixin and ListMixin to get the full behavior.
Making a composite mixin, even if only by "class ListMixin = _ListBase with IterableMixin;" declarations, that can be used by itself avoids code duplication while keeping a usable set of mixin classes.

(Remove some more restrictions, and we won't have to have separate Mixin and Base classes, which would be awesome!)

[natebosch]

@leafpetersen - is this covered by the super mixins proposal?

[leafpetersen]

@lrhn I think this is still on your wishlist, but I don't think we really need this to track the feature do we? Feel free to re-open if you want to keep this one around.

[lrhn]

I think I'll keep it open for now. It is a wish, even for the platform libraries (our ListMixin duplicates code from IterableMixin because we can't reuse code in a mixin).

The new syntax will definitely make it easier to define composite mixins.

[lrhn]

Marking as request since this does not specify a specific approach to introducing composite mixins, just the issue that you can't.

[feinstein]

Having something as:

mixin A with B {
  void methodFromA() {
    methodFromB();
  }
}

Would be a very nice refinement on the language

[stephenbunch]

Another issue related to mixin composition is that we can't express a generic type T that extends more than one interface. So if I have four mixins, and I want to create a generic method that only accepts objects that implement two of those mixins, I can't do that.

Java supports multiple bounds with & syntax: https://docs.oracle.com/javase/tutorial/java/generics/bounded.html
C# also supports multiple type constraints using commas: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/constraints-on-type-parameters