You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's sometimes useful to have a mixin which can do super-invocations.
This was allowed in Dart 1. That implementation is still being used by Flutter code because they are using the feature. We should add the feature to the language again, so we can move the Flutter code off the old implementation.
The reason the Dart 1 specification of "super mixins" was removed again was that it didn't work well in a more strongly typed language (it made all super-invocations effectively dynamic invocations) and it was never implemented by dart2js. It also did not meet the use-cases that were actually being addressed, for example it was only possible to give one super-type.
The alternative we introduce should address the current need, and we should introduce a syntax which allows more mixin features to be added in the future. For that reason it must not use a class declaration like in Dart 1. It was impossible to see whether a class declaration was intended to be a class, or just intended to be a mixin. We have reserved the mixin identifier as a built-in identifier in Dart 2.
Uh oh!
There was an error while loading. Please reload this page.
It's sometimes useful to have a mixin which can do super-invocations.
This was allowed in Dart 1. That implementation is still being used by Flutter code because they are using the feature. We should add the feature to the language again, so we can move the Flutter code off the old implementation.
The reason the Dart 1 specification of "super mixins" was removed again was that it didn't work well in a more strongly typed language (it made all super-invocations effectively dynamic invocations) and it was never implemented by dart2js. It also did not meet the use-cases that were actually being addressed, for example it was only possible to give one super-type.
The alternative we introduce should address the current need, and we should introduce a syntax which allows more mixin features to be added in the future. For that reason it must not use a
class
declaration like in Dart 1. It was impossible to see whether a class declaration was intended to be a class, or just intended to be a mixin. We have reserved themixin
identifier as a built-in identifier in Dart 2.Solutions: #7.
The text was updated successfully, but these errors were encountered: