\section{Open Problems / ..}

\subsection{Developing a Module in JavaScript}

Even though the syntax of JavaScript modules are standardized for some time now,
the actual semantics are still in flux. 

- Modules can have state and change it 
- So it is not clear how much of a module will be


What can happen if a programmer changes code in a module?

- changed classes / or module function
- added classes / or module functions (state in a module)
- removed classes / or module functions

changed classes can mean:
- method changes
- added methods 
- removed methods

- some are public (export) and some are private (no export)

- these changes can be arbitrarily nested

- imperative code / e.g. used for initialization


\subsection{How live can we get? Workflow?}

[Hancock, Tanimoto, Ungar]

- compile and run, use and get feedback  [Tanimoto Level1]
	- JavaScript F5 development? 

- edit triggered update

- program runs, and parts of it are reloaded (Smalltalk)
	- state can be preserved
    - no guarantied feedback 

- program runs, edit changes, and context is recreated (mutable past)

\subsection{bootstrapping / self supporting system}

\subsection{Dealing with module identity}

Is there only one module for one name in the system, or could there
be multiple versions. 

\begin{itemize}
\item a) Half of the system works still with the old module and the other half works with the new one.

\item b) There is just one instance of a module at any time and old references will point to an updated version of a module. This can be implemented by carefully updating the inner state of a module and not changing its identity at all. Or a system with a smalltalk like "become" can change instances. Or a proxy can make sure that every user of a module only keeps the reference of the proxy and the proxy delegates to the appropriate/current version of the module.
\end{itemize}

Real problem: Event listeners hold references to old module instances. 

Idiom to get around problem: make event listeners always dispatch with an indirection to the new objects. (e.g. one global registry knows the latest modules)
