dart-lang/sdk
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

Adjusted superclasses to make a mixin application superclass abstract

Browse Source 
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>
This commit is contained in:
Erik Ernst
2018-09-26 13:44:28 +00:00
parent b480089a1a
commit e05f1fc32d
1 changed files with 22 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/language/dartLangSpec.tex
+22 -4
View File
@@ -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}
<superclass> ::= \EXTENDS{} <type>