`mixin` should be able to `extend` another `mixin`

This issue affects both the analyzer and the VM.

What I was doing

Attempted to have one mixin extend another. I get the following bouquet of analysis errors.

mixin A {}
mixin B extends A {}
//      ^
//      "Variables must be declared using the keywords 'const', 'final', 'var' or a type name."
//      "Document all public members."
//      "Expected an identifier."
//      "A class or mixin definition must have a body, even if it is empty."
//      "Prefer typing uninitialized variables and fields."
//      "Expected to find ';'."
//      "Missing variable type for 'extends'."

Flutter uses this capability to allow one mixin automatically bring another mixin into the mix (example).

One possible workaround is to have the user mix in all the mixins necessary. However, this is not possible when some of the mixins are private, like in the aforementioned example.

Versions

  • Flutter SDK 0.4.3-pre.1162
  • Visual Studio Code 1.27.1
  • Dart Code 2.18.0

@stereotype441 @JekCharlsonYu @leafpetersen

Author: Fantashit

1 thought on “`mixin` should be able to `extend` another `mixin`

  1. I don’t think we want to extend mixins. We only use the extends keyword because there is no alternative. What we’re looking for is that one mixin can automatically bring other mixins with it, some of which may be private. Let’s pretend includes keyword exists just for that:

    // mixins.dart
    mixin M2 { }
    mixin M1 includes M2 { }
    
    // a.dart
    class A extends Object with M1 { }

    We could desugar the above into the following:

    // mixins.dart
    mixin M2 { }
    mixin M1 on M2 { }
    
    // a.dart
    class A extends Object with M1, M2 { }

    The only extra capability the former syntax has is that M2 can be private. This is because the application of M1 does not mention M2 by name. There would not be any other semantic difference between the former and the latter examples.

    Having said that, in the listener_helpers.dart case _ListenerMixin can easily become an interface (thanks @vsmenon for the idea!). If I do not find any other instances of mixins extending other mixins I’ll close the issue.

Comments are closed.