From e05f1fc32d9900d59141a949eefc206c039d428c Mon Sep 17 00:00:00 2001 From: Erik Ernst Date: Wed, 26 Sep 2018 13:44:28 +0000 Subject: [PATCH] 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 --- docs/language/dartLangSpec.tex | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex index 18169801c98..a221897117e 100644 --- a/docs/language/dartLangSpec.tex +++ b/docs/language/dartLangSpec.tex @@ -2571,17 +2571,35 @@ Static method declarations may conflict with other declarations \subsection{Superclasses} \LMLabel{superclasses} +%% TODO(eernst): We need to say that the superclass which is obtained +%% by mixin application is generic when $C$ is generic, or at least +%% when one or more of $C$'s type variables are used by the classes +%% in the \EXTENDS{} or \WITH{} clause of $C$. It says below that +%% these clauses are in the type parameter scope of $C$, but that does +%% not allow us to talk about the superclass as an actual, stand-alone +%% class (unless we start defining nested classes, such that the +%% superclass can be declared in that scope). + \LMHash{} -The superclass $S^\prime$ of a class $C$ that has a with clause \code{\WITH{} $M_1, \ldots,\ M_k$} and an extends clause \code{\EXTENDS{} $S$} is the application of mixin composition (\ref{mixins}) $M_k* \cdots * M_1$ to $S$. The name $S^\prime$ is a fresh identifier. -If no \WITH{} clause is specified then the \EXTENDS{} clause of a class $C$ specifies its superclass. +The superclass $S'$ of a class $C$ whose declaration has a with clause +\code{\WITH{} $M_1, \ldots,\ M_k$} +and an extends clause +\code{\EXTENDS{} $S$} +is the abstract class obtained by application of +mixin composition (\ref{mixins}) $M_k* \cdots * M_1$ to $S$. +The name $S'$ is a fresh identifier. +If no \WITH{} clause is specified then the \EXTENDS{} clause of +a class $C$ specifies its superclass. If no \EXTENDS{} clause is specified, then either: \begin{itemize} \item $C$ is \code{Object}, which has no superclass. OR -\item Class $C$ is deemed to have an \EXTENDS{} clause of the form \code{\EXTENDS{} Object}, and the rules above apply. +\item Class $C$ is deemed to have an \EXTENDS{} clause of the form +\code{\EXTENDS{} Object}, and the rules above apply. \end{itemize} \LMHash{} -It is a compile-time error to specify an \EXTENDS{} clause for class \code{Object}. +It is a compile-time error to specify an \EXTENDS{} clause +for class \code{Object}. \begin{grammar} ::= \EXTENDS{}