\begin{abstract}

\end{abstract}

\section{Introduction}

\end{lstlisting}

\end{figure}

The case of \jscode{target.addEventListener(name, listener)} is a bit different. The \jscode{name} parameter defines the event to listen to and the \jscode{listener} parameter the function to call back each time such an event occurs. Instead of being polymorphic in its return type, it is polymorphic in its \jscode{listener} parameter. Nevertheless, a similar property as above holds: there is exactly one possible type for the \jscode{listener} parameter for each value of the \jscode{name} parameter. For instance, a listener of \jscode{'click'} events is a function taking a \jscode{MouseEvent} parameter, a listener of \jscode{'keydown'} events is a function taking a \jscode{KeyboardEvent} parameter, and so on. The same pattern as above (defining a set of functions fixing the \jscode{name} parameter value) can be used to encode this function in a statically typed language, but an alternative encoding could be to define one function taking one parameter carrying both the information of the event name and the event listener. Listing~\ref{lst-add-event-listener-one-param} shows such an encoding in Java.

The case of\jscode{target.addEventListener(name, listener)} is a bit different. The\jscode{name} parameter defines the event to listen to and the\jscode{listener} parameter the function to call back each time such an event occurs. Instead of being polymorphic in its return type, it is polymorphic in its\jscode{listener} parameter. Nevertheless, a similar property as above holds: there is exactly one possible type for the\jscode{listener} parameter for each value of the\jscode{name} parameter. For instance, a listener of\jscode{'click'} events is a function taking a\jscode{MouseEvent} parameter, a listener of\jscode{'keydown'} events is a function taking a\jscode{KeyboardEvent} parameter, and so on. The same pattern as above (defining a set of functions fixing the\jscode{name} parameter value) can be used to encode this function in a statically typed language, but an alternative encoding could be to define one function taking one parameter carrying both the information of the event name and the

event listener. Listing~\ref{lst-add-event-listener-one-param} shows such an encoding in Java.

\begin{figure}

\begin{lstlisting}[label=lst-add-event-listener-one-param,language=Java,caption={Encoding of the \jscode{target.addEventListener(name, listener)} function in Java using one paremeter carrying both the information of the event name and the event listener}]

\item Use type\scalacode{U} instead of type\scalacode{T}

\end{enumerate}

Listing~\ref{lst-generics-dom} shows this approach applied to the\jscode{createElement} function: we created a type\scalacode{ElementName<E>}, the\scalacode{name} parameter is not a\scalacode{String} but a\scalacode{ElementName<E>}, and the function returns an\scalacode{E} instead of an\scalacode{Element}. The\scalacode{ElementName<E>} type encodes the relationship between the name of an element and the type of this element. For instance, we created a value\scalacode{Input} of type\scalacode{ElementName<InputElement>}. The last two lines shows how this API is used by end developers: by passing the\scalacode{Input} value as parameter to the function, it fixes the type parameter\scalacode{E} to\scalacode{InputElement} so the returned value has the most possible precise type.

Listing~\ref{lst-generics-dom} shows this approach applied to the\jscode{createElement} function: we created a type\scalacode{ElementName<E>}, the\scalacode{name} parameter is not a\scalacode{String} but a\scalacode{ElementName<E>}, and the function returns an\scalacode{E} instead of an\scalacode{Element}. The\scalacode{ElementName<E>} type encodes the relationship between the name of an element and the type of this element\footnote{The type parameter\scalacode{E} is also called a\emph{phantom type}~\cite{leijen1999domain} because\scalacode{ElementName} values never hold a\scalacode{E} value}. For instance, we created a value\scalacode{Input} of type\scalacode{ElementName<InputElement>}. The last two lines shows how this API is used by end developers: by passing the\scalacode{Input} value as parameter to the function, it fixes the type parameter\scalacode{E} to\scalacode{InputElement} so the returned value has the most possible precise type.

\begin{figure}

\begin{lstlisting}[label=lst-generics-dom,language=java]

\end{lstlisting}

\end{figure}

We show that our encodings support the challenging functions defined in listings\ref{lst-js-comb} and\ref{lst-js-react}.

Listing\ref{lst-generics-comb} and\ref{lst-generics-react} show how these functions can be implemented. They are basically a direct translation from JavaScript to Java.

\begin{figure}

\begin{lstlisting}[label=lst-generics-comb,language=java]

<A, B> void createAndListenTo(

ElementName<A> tagName,

EventName<B> eventName,

Function2<A, B, Void> listener) {

A element = document.createElement(tagName);

element.addEventListener(eventName, event -> listener.apply(event, element));

}

\end{lstlisting}

\end{figure}

\begin{figure}

\begin{lstlisting}[label=lst-generics-react,language=java]

<A> Function<Function<A, Void>, Void> observe(EventTarget target, EventName<A> name) {

return listener -> {

target.addEventListener(name, listener);

}

}

\end{lstlisting}

\end{figure}

Our encoding makes it possible to implement exactly the same functions as we are able to implement in plain JavaScript, but with type safety.

However, every function taking an element name or an event name as parameter must have type parameters too, making its type signature harder to read.

\subsection{Path-Dependent Types}

This section shows how we can remove the extra type parameters needed in the previous section by using\emph{path-dependent types}. Essentially, the idea is that, instead of using a type parameter, we use a type member. Listings\ref{lst-dt-dom} and\ref{lst-dt-events} show this encoding in Scala. The return type of the\scalacode{createElement} function is\scalacode{name.Element}: it refers to the\scalacode{Element} type member of its\scalacode{name} parameter.

\begin{figure}

\begin{lstlisting}[label=lst-dt-dom]

trait ElementName {

type Element

}

object Div extends ElementName { type Element = DivElement }

object Input extends ElementName { type Element = InputElement }

def createElement(name: ElementName): name.Element = ...

def createElement(name: ElementName): name.Element

\end{lstlisting}

\end{figure}

\begin{figure}

\begin{lstlisting}[label=lst-dt-events]

trait EventName {

typeData

typeEvent

}

object Click extends EventDef { type Data = MouseEvent }

def on(name: EventName)(handler: Rep[name.Data] => Rep[Unit]): Rep[Unit]

object Click extends EventDef { type Event = MouseEvent }

val clicks = on(Click)

clicks(event => println(event.offsetX))

trait EventTarget {

def addEventListener(name: EventName)(handler: name.Event => Unit): Unit

}

\end{lstlisting}

\end{figure}

\section{Validation}

\label{sec-validation}

We show that our encodings support the challenging functions defined in listings\ref{lst-js-comb} and\ref{lst-js-react}.

Listing\ref{lst-generics-comb} and\ref{lst-generics-react} show how these functions can be implemented. They are basically a direct translation from JavaScript to Java.

Implementing listings\ref{lst-js-comb} and\ref{lst-js-react} using this encoding is straightforward, as shown by listings\ref{lst-dt-comb} and\ref{lst-dt-react}, respectively.

\begin{figure}

\begin{lstlisting}[label=lst-generics-comb,language=java]

<A, B> void createAndListenTo(

ElementName<A> tagName,

EventName<B> eventName,

Function2<A, B, Void> listener) {

A element = document.createElement(tagName);

element.addEventListener(eventName, event -> listener.apply(event, element));

\begin{lstlisting}[label=lst-dt-comb]

def createAndListenTo(tagName: ElementName, eventName: EventName, listener: (eventName.Event, tagName.Element) => Unit) = {

val element = document.createElement(tagName)

element.addEventListener(eventName)(event => listener(event, element))

}

\end{lstlisting}

\end{figure}

\begin{figure}

\begin{lstlisting}[label=lst-generics-react,language=java]

<A> Function<Function<A, Void>, Void> observe(EventTarget target, EventName<A> name) {

return listener -> {

target.addEventListener(name, listener);

}

}

\begin{lstlisting}[label=lst-dt-react]

def observe(target: EventTarget, name: EventName) =

(listener: (name.Event => Unit)) => target.addEventListener(name)(listener)

\end{lstlisting}

\end{figure}

With this encoding, the functions using event names or element names are not anymore cluttered with type parameters.

\section{Validation}

\label{sec-validation}

\subsection{Implementation in js-scala}

We implemented our pattern in js-scala~\cite{Kossakowski12_JsDESL}, a Scala library providing JavaScript code generators\footnote{Source code is available at\href{http://github.com/js-scala}{http://github.com/js-scala}}.

\subsection{Limitations}

We do not help with\jscode{getElementById}.

\section{Conclusion}

\label{sec-conclusion}

We presented two ways to encode dynamically typed browser functions in mainstream statically typed languages like Java and Scala, using\emph{generics} or path-dependent types. Our encoding gives more type safety than existing solutions, while keeping the same expression power and modularity level as the native API.

\bibliographystyle{plain}

\bibliography{references.bib}

@comment{x-kbibtex-personnameformatting=<%l><, %f>}

@inproceedings{leijen1999domain,

title={Domain specific embedded compilers},

author={Leijen, Daan and Meijer, Erik},

booktitle={ACM Sigplan Notices},

volume={35},

number={1},

pages={109--122},

year={1999},

organization={ACM}

}

@incollection{liberty2011reactive,

title={Reactive Extensions for JavaScript},

author={Liberty, Jesse and Betts, Paul},