languages/dart-sdk
languages/dart-sdk
1
0
Fork 0
mirror of https://github.com/dart-lang/sdk synced 2024-09-05 16:41:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

Adjusted spec to make it an error to have a method - getter/setter clash

Browse source 
Currently, this kind of clash is an error when there is a declaration
at which the conflict is known to be an error, but it was not an error
when it occurs because a class `implements` two other classes where one
provides the getter/setter and the other provides the method.

Note to implementors: The analyzer apparently already flags this
situation as an error, so the change should be non-breaking, and if
implementation changes are needed at all it would most likely only be
in other tools.

Bug: https://github.com/dart-lang/sdk/issues/35561
Change-Id: I7f55b8995829ad64b86ebf33045b235813fc5161
Reviewed-on: https://dart-review.googlesource.com/c/88455
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This commit is contained in:
Erik Ernst 2019-01-08 08:46:36 +00:00
parent b58e8d7307
commit cba23af8ce
1 changed files with 32 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
docs/language/dartLangSpec.tex
View file

@ -26,9 +26,12 @@
% =======
% Significant changes to the specification.
% 2.2
% - Specify whether the values of literal expressions override Object.==.
% - Allow Type objects as case expressions and const map keys.
% - Introduce set literals.
% - Specify whether the values of literal expressions override Object.==.
% - Allow Type objects as case expressions and const map keys.
% - Introduce set literals.
% - Specify that a getter/setter and a method with the same basename is
% an error, also in the case where a class obtains both from its
% superinterfaces.
%
% 2.1
% - Remove 64-bit constraint on integer literals compiled to JavaScript numbers.
@ -3659,16 +3662,32 @@ the basename of a setter named \code{$n$=} is $n$.
\LMHash{}%
Let $C$ be a class.
It is a compile-time error if $C$ declares a
\begin{itemize}
\item constructor named \code{$C$.$n$} and a static member with basename $n$.
\item getter or a setter with basename $n$, and has a method named $n$.
\item method named $n$, and has a getter or a setter with basename $n$.
\item static member with basename $n$, and has an instance member with basename $n$.
\end{itemize}
It is a compile-time error if $C$
declares a constructor named \code{$C$.$n$} and
a static member with basename $n$.
It is a compile-time error if $C$
declares a static member with basename $n$ and
the interface of $C$ has an instance member with basename $n$.
It is a compile-time error if the interface of $C$
has a method named $n$ and a setter with basename $n$.
\LMHash{}%
These errors occur when the getters or setters are defined explicitly
as well as when they are induced by variable declarations.
\commentary{%
Note that other errors which are similar in nature are covered elsewhere.
For instance, if $C$ is a class that has two superinterfaces $I_1$ and $I_2$,
where $I_1$ has a method named $m$
and $I_2$ has a getter named $m$,
then it is an error because the computation of the interface of $C$
includes a computation of the combined member signature
(\ref{combinedMemberSignatures})
of that getter and that method,
and it is an error for a combined member signature
to include a getter and a non-getter.
}
\section{Interfaces}
\LMLabel{interfaces}
@ -4117,11 +4136,12 @@ with the same name \id{} to be inherited then
exactly one member is inherited, namely
the combined member signature named \id{},
from the direct superinterfaces
%% TODO(eernst): This is only well-defined when $J$ is a class interface.
% This is well-defined because $I$ is a class interface.
in the textual order that they are declared,
with respect to $L$
(\ref{combinedMemberSignatures}).
It is a compile-time error
if the computation of said combined member signature fails.
\subsubsection{Correct Member Overrides}
\LMLabel{correctMemberOverrides}