

% add the PATH to retrieve cls and sty beamer styles files
\makeatletter
\providecommand*{\input@path}{}
\edef\input@path{{../../support/beamer/}\input@path}% prepend
\makeatother

% \documentclass{pharoslides}
% \documentclass[aspectratio=169]{pharoslides} % format 16/9
\documentclass[withvideo]{pharoslides} % format 16/9 + incrustation video

\graphicspath{{./figures/}{../}{../../support/beamer/imgs/}}

%Information to be included in the title page:
\title{Overloading in Java}
\subtitle{Why you should not use it}
\author{Damien Cassou, Stéphane Ducasse and Luc Fabresse}
\institute{http://stephane.ducasse.free.fr}
\date{}
\slidesid{}

\begin{document}

\frame[plain]{\titlepage}



\begin{frame}[fragile]

\frametitle{Goal}

\begin{itemize}
\item What is overloading?
\item Why is it a problem?
\item What can you do?
\end{itemize}

This lecture is in the context of the Java programming language.

\begin{itemize}
\item It is an incentive to understand for real double dispatch (without overloading)
\end{itemize}
\end{frame}



\begin{frame}[fragile]

\frametitle{Overloading}

Overloading: methods sharing a name.

\begin{listing}{}
public class OverloadingSimple {
   public String m(int a) {
      return "my parameter is an int";
   }
   public String m(String b) {
      return "my parameter is a string";
   }
   public static void main(String[] args) {
      System.out.println(new OverloadingSimple().m(123));
      System.out.println(new OverloadingSimple().m("a"));
   }
}
\end{listing}

Seems nice at first to avoid thinking about names.
\end{frame}



\begin{frame}[fragile]

\frametitle{Exercise}

\begin{listing}{}
class A {
   public void f(A a) { print("A.f(A)"); }
}
class B extends A {
   public void f(A a) { print("B.f(A)"); }
   public void f(B b) { print("B.f(B)"); }
}

A a = new B(); // take care, this is a B!
B b = new B();
a.f(a);      a.f(b);
b.f(a);      b.f(b);
\end{listing}

What are the results of these 4 expressions?
\end{frame}



\begin{frame}[fragile]

\frametitle{Solution}

\begin{listing}{}
class A {
   public void f(A a) { print("A.f(A)"); }
}
class B extends A {
   public void f(A a) { print("B.f(A)"); }
   public void f(B b) { print("B.f(B)"); }
}

A a = new B(); // take care, this is a B!
B b = new B();
a.f(a);      a.f(b);
b.f(a);      b.f(b);
\end{listing}

\begin{tabular}{ll}
\toprule
B.f(A) & B.f(A) \\
B.f(A) & B.f(B) \\
\bottomrule
\end{tabular}
\end{frame}



\begin{frame}[fragile]

\frametitle{Explanation}

Overloading + sub-typing is confusing in Java.

In the presence of a message send, the compiler searches a \textit{compatible signature} and stores it. During execution, the lookup algorithm searches for a method with this exact signature, regardless of the dynamic types of arguments.
\end{frame}



\begin{frame}[fragile]

\frametitle{Looking at a Real Case: a Visitor}

\begin{listing}{}
public class A {
   public void accept(Visitor visitor) {
      visitor.visit(this);
   }
}
public class Visitor {
   public void visit(A a) {
      System.out.println("Visitor.visit(A)");
   }
}

Visitor visitor = new Visitor();
new A().accept(visitor); // "Visitor.visit(A)"
\end{listing}

All is well in this perfect world...
\end{frame}



\begin{frame}[fragile]

\frametitle{Uh! My Visitor is not Executed!}

\begin{listing}{}
public class SubA extends A {
   public void accept(Visitor visitor) {
      visitor.visit(this);
   }
}
public class SubVisitor extends Visitor {
   public void visit(SubA subA) {
      System.out.println("SubVisitor.visit(SubA)");
   }
}

Visitor visitor = new SubVisitor();
new SubA().accept(visitor);  // "Visitor.visit(A)"
\end{listing}

When method \code{SubA.accept()} is compiled, the message \code{visitor.visit(this)} is bound to \code{visit(A)}, the only compatible signature in \code{Visitor}. During execution, \code{visit(SubA)} is ignored.
\end{frame}



\begin{frame}[fragile]

\frametitle{Possible Ugly 'Solutions'}

One way to fix that could be to add a \code{visit(SubA)} method in \code{Visitor} (if you can change it):

\begin{listing}{}
public class Visitor {
   public void visit(A a) {
      System.out.println("Visitor.visit(A)");
   }
   public void visit(SubA a) {
      System.out.println("Visitor.visit(SubA)");
   }
}
\end{listing}

This works but has 2 problems (see next slides):

\begin{itemize}
\item the methods \code{accept()} in \code{A} and \code{SubA} are identical
\item you can't use the \code{visit()} methods directly
\end{itemize}
\end{frame}



\begin{frame}[fragile]

\frametitle{In Particular}

The methods \code{accept()} in \code{A} and \code{SubA} are identical:

\begin{listing}{}
public class A {
   public void accept(Visitor visitor) {
      visitor.visit(this);
   }
}
public class SubA extends A {
   public void accept(Visitor visitor) {
      visitor.visit(this);
   }
}
\end{listing}

You could think that \code{SubA.accept()} is useless because its content is the same as \code{A.accept()}. But it's not useless as, inside it, the message \code{visitor.visit(this)} binds to the signature \code{visit(SubA)} which is what we want.
\end{frame}



\begin{frame}[fragile]

\frametitle{In Particular}

You can't use the \code{visit()} methods directly:

\begin{listing}{}
public class Visitor {
   public void visit(A a) {
      System.out.println("Visitor.visit(A)");
   }
   public void visit(SubA a) {
      System.out.println("Visitor.visit(SubA)");
   }
}

Visitor visitor = new Visitor();
A subA = new SubA();
visitor.visit(subA); // "Visitor.visit(A)"
\end{listing}

If you use the visitor directly (i.e., without going through \code{accept()} methods), the static types become important to decide which \code{visit()} method to execute.
\end{frame}



\begin{frame}[fragile]

\frametitle{The Real Solution}

Don't use overloading and prefer dedicated method names:

\begin{listing}{}
public class A {
   public void accept(Visitor visitor) {
      visitor.visitA(this);
   }
}

public class Visitor {
   public void visitA(A a) {
      System.out.println("Visitor.visitA(A)");
   }
}
\end{listing}
\end{frame}



\begin{frame}[fragile]

\frametitle{Summary}

\begin{enumerate}
\item overloading is nice
\item just pay attention you don't mix it with sub-typing...
\item but OO programming is all about sub-typing...
\item don't use overloading
\end{enumerate}
\end{frame}




% \setlength{\textwidth}{\originaltextwidth}
\setbeamertemplate{background canvas}{\insertBorderForHandout}

\begin{frame}[plain]

\begin{minipage}{\originaltextwidth}
\centering
\large


\vspace{2em}

A course by

\vspace{1em}

\hspace{-20px}\includegraphics[height=32px]{inriaLogo}\hspace{3em}\raisebox{7px}{and}\hspace{3em}\raisebox{-6px}{\includegraphics[height=30px]{logoutop}}

\vspace{2em}

in collaboration with

\vspace{1em}

\includegraphics[height=40px]{unisciellogo}\hskip 1.5em%
\raisebox{5px}{\includegraphics[height=30px]{unitlogo}}\hskip 2em%
\raisebox{8px}{\includegraphics[height=24px]{univLilleLogo}}\hskip 2em%
\raisebox{3px}{\includegraphics[height=29px]{logo-IMT}}\hskip 2em%
\raisebox{1px}{\includegraphics[height=32px]{minesDouaiLogo}}

\vspace{2.5em}

\includegraphics[width=50px]{by-nc-nd} \tiny \hskip 0.5em \raisebox{5px}{Inria 2016}

\medskip

\tiny
Except where otherwise noted, this work is licensed under CC BY-NC-ND 3.0 France

\url{https://creativecommons.org/licenses/by-nc-nd/3.0/fr/} 

\end{minipage}
\end{frame}

\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:
