Erik Ernst e05f1fc32d Adjusted superclasses to make a mixin application superclass abstract ... We should avoid the situation where `class C extends A with M {}` requires generation of noSuchMethod forwarders _in the superclass `A with M`_ when neither `A` nor `M` has an implementation of `foo`, but `A with M` has a non-trivial noSuchMethod. If we _do_ generate those nSM forwarders, that will just obscure that any attempt to invoke `super.foo()` in `C` should be an error. Note that this is about generating forwarders _in the mixin application which is the superclass_, it is not about copy-down of forwards from the class `M` that was used to obtain the mixin in the first place. Also note that it would be inconvenient to require all methods to be implemented in `A with M` as used in `abstract C extends A with M {}`, and it would also be rather funny if we were to say that `A with M` is abstract when `C` is abstract, and concrete when `C` is concrete. So I think the only reasonable choice is to make those superclasses which are mixin applications abstract. Note that dart:mirrors ought to reflect this, in a separate issue, if it is not already the case. Change-Id: If221b2c73b17bd55017d4d5ee4fdb8daf203e195 Reviewed-on: https://dart-review.googlesource.com/76640 Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>		2018-09-26 13:44:28 +00:00
..
language	Adjusted superclasses to make a mixin application superclass abstract	2018-09-26 13:44:28 +00:00
newsletter	Newsletter 2017-11-24.	2017-11-24 16:27:00 +00:00