Updated after review
diff --git a/design/N4JSDesign.html b/design/N4JSDesign.html
index 8a7d6d8..6e1e07a 100644
--- a/design/N4JSDesign.html
+++ b/design/N4JSDesign.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -853,7 +853,7 @@
<div id="preamble">
<div class="sectionbody">
<div class="paragraph center">
-<p><strong>Last Updated: 2019-08-07</strong></p>
+<p><strong>Last Updated: 2019-08-08</strong></p>
</div>
<div class="paragraph center">
<p><strong>Authors:</strong><br>
@@ -1357,7 +1357,7 @@
<p>change to "Advance Mode" via the menu (upper-right corner) (no need to move the installer)</p>
</li>
<li>
-<p>select a product, e.g. "Eclipse IDE for Eclipse Committers" with product version "latest"</p>
+<p>select a product, e.g. "Eclipse IDE for Eclipse Committers" with product version "2019-06". Hint: Do not select "latest" because this will cause automatic updates which may lead to weird errors later on.</p>
</li>
<li>
<p>double-click the entry <strong>Eclipse Projects/N4JS</strong> so that it is shown in the catalog view below</p>
@@ -1378,7 +1378,7 @@
</div>
<div class="paragraph">
<p>Eventually the installer scripts are done, that means the git repository has been cloned and the workspace has been configured (including the project set setup).
-Now the automatic build kicks in as you can see in the status bar. Screenshot 6</p>
+Now the automatic build kicks in as you can see in the status bar.</p>
</div>
<div class="paragraph">
<p>The build will show a lot of errors while still working. Eventually the whole project should have been compiled without any errors. Unfortunately, due to a <a href="https://github.com/eclipse/n4js/issues/1373">known issue</a>, two problems exists. Please have a look at the linked issue on how to fix that (it is quite easy).</p>
@@ -16895,7 +16895,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/N4JSDesign.xml b/design/N4JSDesign.xml
deleted file mode 100644
index a0c7824..0000000
--- a/design/N4JSDesign.xml
+++ /dev/null
@@ -1,12752 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<?asciidoc-toc maxdepth="5"?>
-<?asciidoc-numbered maxdepth="5"?>
-<book xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
-<info>
-<title>N4JS Design Specification</title>
-<date>2019-08-07</date>
-<author>
-<personname>
-<firstname>2019-08-07 15:02:40 CEST</firstname>
-</personname>
-</author>
-<authorinitials>{</authorinitials>
-<style>
- .admonitionblock td.icon .icon-todo:before{content:"\f249";color:#f4ee42}
- </style>
-</info>
-<preface>
-<title></title>
-<simpara role="center"><emphasis role="strong">Last Updated: 2019-08-07</emphasis></simpara>
-<simpara role="center"><emphasis role="strong">Authors:</emphasis><?asciidoc-br?>
-Jens von Pilgrim, Jakub Siberski, Mark-Oliver Reiser, Torsten Krämer, Ákos Kitta, Sebastian Zarnekow, Lorenzo Bettini, Jörg Reichert, Kristian Duske, Marcus Mews, Minh Quang Tran, Luca Beurer-Kellner</simpara>
-<simpara><?asciidoc-pagebreak?></simpara>
-<simpara>This document contains the N4JS Design and Implementation documentation.</simpara>
-<simpara><?asciidoc-pagebreak?></simpara>
-</preface>
-<chapter xml:id="_introduction">
-<title>Introduction</title>
-<simpara>This document describes design aspects of the N4JS compiler and IDE. It relies on the following N4JS related specifications:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>N4JS Language Specification [<link linkend="N4JSSpec">N4JSSpec</link>]</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="notation">
-<title>Notation</title>
-<simpara>We reuse the notation specified in [<link linkend="N4JSSpec">N4JSSpec</link>].</simpara>
-</section>
-<section xml:id="sec:IDE_Overview">
-<title>IDE Components</title>
-<simpara>The N4JS and N4JSIDE components are organized via features. The following features with included plugins are defined
-(the common prefix "org.eclipse.n4js" is omitted at the plugin name):</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="5.8823*"/>
-<colspec colname="col_2" colwidth="11.7647*"/>
-<colspec colname="col_3" colwidth="82.353*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Feature</entry>
-<entry align="left" valign="top">Plugin</entry>
-<entry align="left" valign="top">Description</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.lang.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>N4JS core language with parser, validation etc.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>org.eclipse.n4js</simpara></entry>
-<entry align="left" valign="top"><simpara>Xtext grammar with generator and custom code for N4JS, scoping (and binding) implementation, basic validation (and Xsemantics type system).</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>doc</simpara></entry>
-<entry align="left" valign="top"><simpara>(in doc folder) General documentation (including web page) written in AsciiDoc</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>external.libraries</simpara></entry>
-<entry align="left" valign="top"><simpara>Support for N4JS libraries shipped with the IDE, i.e. core N4JS library and mangelhaft.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI components for N4JS, e.g., proposal provider, labels, outline, quickfixes.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>jsdoc</simpara></entry>
-<entry align="left" valign="top"><simpara>Parser and model for JSDoc</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>external.libraries.update</simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Not included in feature</emphasis>. Updates the external library plugin</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.ts.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Type System</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>ts</simpara></entry>
-<entry align="left" valign="top"><simpara>Xtext grammar with generator and custom code for type expressions and standalone type definitions.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>ts.model</simpara></entry>
-<entry align="left" valign="top"><simpara>Xcore based types model with helper classes etc.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>ts.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>Xtext generated UI for type system, not really used as this TS files are not editable by users.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.unicode.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>common.unicode</simpara></entry>
-<entry align="left" valign="top"><simpara>Xtext grammar with generator and custom code used by all other grammars for proper unicode support.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.regex.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Regular expression grammar and UI, used by N4JS grammar and UI</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>regex</simpara></entry>
-<entry align="left" valign="top"><simpara>Xtext grammar with generator and custom code used by N4JS grammars for regular expressions.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>regex.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI components for regular expressions, e.g., proposal provider, labels, outline, quickfixes.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>This feature defines the N4JSIDE. It contains core UI plugins and all includes (almost all) other features!</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>environments</simpara></entry>
-<entry align="left" valign="top"><simpara>Utility plugin, registers n4scheme for EMF proxy resolution.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>model</simpara></entry>
-<entry align="left" valign="top"><simpara>Xcore based N4JS model with helper classes etc.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>product</simpara></entry>
-<entry align="left" valign="top"><simpara>N4JSIDE main application.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>releng.utils</simpara></entry>
-<entry align="left" valign="top"><simpara>(in releng folder) Contains utility classes only used for building the system, e.g., tools for generating antlr based parser with extended features.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>utils</simpara></entry>
-<entry align="left" valign="top"><simpara>general utilities</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>utils.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>general UI utilities</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.compiler.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Compilers and Transpilers</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>generator.common</simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Not included in feature, logically associated.</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>generator.headless</simpara></entry>
-<entry align="left" valign="top"><simpara>N4JS headless generator (i.e. command line compiler).</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>transpiler</simpara></entry>
-<entry align="left" valign="top"><simpara>Generic transpiler infrastructure</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>transpiler.es</simpara></entry>
-<entry align="left" valign="top"><simpara>Transpiler to compile to EcmaScript</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.json.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>N4JS JSON</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>json</simpara></entry>
-<entry align="left" valign="top"><simpara>Xtext grammar with generator and custom code for a extensible JSON language support. Used in N4JS for the project description in terms of a <literal>package.json</literal> file.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>json.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI components for extensible JSON language support, e.g., proposal provider, labels, outline.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>json.model</simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Not included in feature, logically associated.</emphasis> Xcore based model for the JSON language.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.semver.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Semantic version string support.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>semver</simpara></entry>
-<entry align="left" valign="top"><simpara>Parser and tools for semantic version strings.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>semver.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI tools for semantic version strings.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>semver.model</simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Not included in feature, logically associated.</emphasis> Xcore model of semantic version strings.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.runner.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Runners for executing N4JS or JavaScript code</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>runner</simpara></entry>
-<entry align="left" valign="top"><simpara>Generic interfaces and helper for runners, i.e. JavaScript engines executing N4JS or JavaScript code.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>runner.chrome</simpara></entry>
-<entry align="left" valign="top"><simpara>Runner for executing N4JS or JavaScript with Chrome.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>runner.chrome.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI classes for launching the Chrome runner via the org.eclipse.debug.ui</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>runner.nodejs</simpara></entry>
-<entry align="left" valign="top"><simpara>Runner for executing N4JS or JavaScript with node.js.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>runner.nodejs.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI classes for launching the node.js runner via the org.eclipse.debug.ui</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>runner.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>Generic interfaces for configuring N4JS runner via the debug ui.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.tester.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Runners and UI for tests (via mangelhaft).</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>tester</simpara></entry>
-<entry align="left" valign="top"><simpara>Generic interfaces and helper for testers, i.e. JavaScript engines executing N4JS tests (using mangelhaft).</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>tester.nodejs</simpara></entry>
-<entry align="left" valign="top"><simpara>Tester based on the nodejs runner for executing mangelhaft tests with node.js</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>tester.nodejs.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI for showing test results.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>tester.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>Configuration of tests via the debug UI.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.jsdoc2spec.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>JSDoc 2 Specification</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>jsdoc2spec</simpara></entry>
-<entry align="left" valign="top"><simpara>Exporter to generate API documentation with specification tests awareness</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>jsdoc2spec.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI for API doc exporter</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.xpect.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>xpect</simpara></entry>
-<entry align="left" valign="top"><simpara>Xpect test methods.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>xpect.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI for running Xpext tests methods from the N4JSIDE (for creating bug reports).</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.smith.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Feature for internal N4JS IDE plugins only intended for development (for example, the AST Graph view).</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>smith</simpara></entry>
-<entry align="left" valign="top"><simpara>Non-UI classes for tools for smiths, that is, tools for developers of the N4JS IDE such as AST views etc.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>smith.ui</simpara></entry>
-<entry align="left" valign="top"><simpara>UI classes for tools for smiths, that is, tools for developers of the N4JS IDE such as AST views etc.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.tests.helper.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Test helpers.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.dependencies.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Collection of all external non-ui dependencies, used for local mirroring of update sites.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">org.eclipse.n4js.dependencies.ui.sdk</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Collection of all external ui dependencies, used for local mirroring of update sites.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_3"><simpara><emphasis role="strong">uncategorized plugins</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>flowgraphs</simpara></entry>
-<entry align="left" valign="top"><simpara>Control and data flow graph model and computer.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">Fragments</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>not associated to features, only listed here for completeness</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>utils.logging</simpara></entry>
-<entry align="left" valign="top"><simpara>Fragment only, configuration for loggers, in particular for the product and for the tests</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<section xml:id="sec:Naming_Conventions">
-<title>Naming Conventions</title>
-<simpara>In the above sections, tests were omitted. We use the following naming conventions (by example) for test and tests helper:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>project</simpara>
-</entry>
-<entry>
-<simpara>-</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.tests</simpara>
-</entry>
-<entry>
-<simpara>tests for project, is a fragment</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.tests.helper</simpara>
-</entry>
-<entry>
-<simpara>helper classes used ONLY by tests</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.tests.performance</simpara>
-</entry>
-<entry>
-<simpara>performance tests</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.tests.integration</simpara>
-</entry>
-<entry>
-<simpara>integration tests</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.ui</simpara>
-</entry>
-<entry>
-<simpara>-</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.ui.tests</simpara>
-</entry>
-<entry>
-<simpara>tests for ui project, fragment of project.ui</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.ui.tests.helper</simpara>
-</entry>
-<entry>
-<simpara>helper classes used ONLY by tests</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.ui.tests.performance</simpara>
-</entry>
-<entry>
-<simpara>-</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>tests.helper</simpara>
-</entry>
-<entry>
-<simpara>general test helper</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>ui.tests.helper</simpara>
-</entry>
-<entry>
-<simpara>general ui test helper</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.xpect.tests</simpara>
-</entry>
-<entry>
-<simpara>xpect tests for the project, despite dependnecies to UI the can be executed as plain JUnit tests</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>project.xpect.ui.tests</simpara>
-</entry>
-<entry>
-<simpara>xpect tests for the project, need to be executed as eclipse plugin tests</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Due to Maven, tests are in subfolder tests (incl. helpers), implementation bundles in plugins, and release engineering related bundles in releng.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_eclipse-setup">
-<title>Eclipse Setup</title>
-<section xml:id="_system-requirements">
-<title>System Requirements</title>
-<simpara>In all cases, <link xl:href="https://adoptopenjdk.net/">Java 11</link> is required to be installed on your system. <link xl:href="https://nodejs.org/en/download/">Node.js</link> version 10+ is also required, and for some tests you need <link xl:href="https://yarnpkg.com">Yarn</link> to be globally installed.</simpara>
-</section>
-<section xml:id="_contribute">
-<title>Contribute</title>
-<simpara>Eclipse developers who want to develop N4JS itself should use the <link xl:href="https://www.eclipse.org/downloads/">Oomph Eclipse installer</link>. The N4JS project is listed under "Eclipse Projects/N4JS"
-This setup installs the correct Eclipse version, creates a new workspace and clones all projects into it (for details see below).</simpara>
-<section xml:id="_eclipse-installer">
-<title>Eclipse Installer</title>
-<simpara>The recommended way to install the Eclipse IDE and set up the workspace is to use the Eclipse Installer.
-This installer is to be downloaded from <link xl:href="https://wiki.eclipse.org/Eclipse_Installer">https://wiki.eclipse.org/Eclipse_Installer</link></simpara>
-<simpara>Run the installer and apply the following steps:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>change to "Advance Mode" via the menu (upper-right corner) (no need to move the installer)</simpara>
-</listitem>
-<listitem>
-<simpara>select a product, e.g. "Eclipse IDE for Eclipse Committers" with product version "latest"</simpara>
-</listitem>
-<listitem>
-<simpara>double-click the entry <emphasis role="strong">Eclipse Projects/N4JS</emphasis> so that it is shown in the catalog view below</simpara>
-</listitem>
-<listitem>
-<simpara>on the next page, configure paths accordingly. You only have to configure the installation and workspace folder. You may want to use git with https instead of ssh.</simpara>
-</listitem>
-<listitem>
-<simpara>start installation</simpara>
-</listitem>
-</orderedlist>
-<simpara>The installer will then guide you through the rest of the installation. All plug-ins are downloaded and configured automatically, so is the workspace including downloading the git repository and setting up the workspace.</simpara>
-<simpara>The workspace is configured automatically. This includes fetching the necessary git repository. If you have selected git with SSH you may run into problems. In this case you can re-run the scripts and select HTTPS instead, this should work in any case.</simpara>
-<simpara>Eventually the installer scripts are done, that means the git repository has been cloned and the workspace has been configured (including the project set setup).
-Now the automatic build kicks in as you can see in the status bar. Screenshot 6</simpara>
-<simpara>The build will show a lot of errors while still working. Eventually the whole project should have been compiled without any errors. Unfortunately, due to a <link xl:href="https://github.com/eclipse/n4js/issues/1373">known issue</link>, two problems exists. Please have a look at the linked issue on how to fix that (it is quite easy).</simpara>
-<section xml:id="_changing-the-setup-script">
-<title>Changing the Setup Script</title>
-<simpara>The setup scripts is stored at</simpara>
-<simpara><literal>n4js/releng/org.eclipse.n4js.targetplatform/N4JS.setup</literal></simpara>
-<simpara>Details about Oomph-Setup scripts can be found at</simpara>
-<simpara><link xl:href="https://wiki.eclipse.org/Eclipse_Installer">https://wiki.eclipse.org/Eclipse_Installer</link></simpara>
-</section>
-</section>
-<section xml:id="_manual-ide-configuration">
-<title>Manual IDE Configuration</title>
-<warning>
-<simpara>Manual IDE configuration is not recommended!</simpara>
-</warning>
-<simpara>For a manual install, clone the code and import all top-level projects from the docs, features, plugins, releng, testhelpers, and tests folders. Activate the targetplatform contained in the <literal>releng/org.eclipse.n4js.targetplatform/</literal> project.</simpara>
-<simpara>The N4JS IDE is developed with Eclipse 2019-06 or better since the system is based on Eclipse anyway.
-It is almost impossible to use another IDE to develop Eclipse plugins. The list of required plugins includes:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Xtext/Xtend 2.18.0</simpara>
-</listitem>
-<listitem>
-<simpara>Xcore 1.9.0</simpara>
-</listitem>
-<listitem>
-<simpara>Xpect 0.2.0.201906240918 from <link xl:href="https://ci.eclipse.org/xpect/job/Xpect-Integration-Release/20/artifact/org.eclipse.xpect.releng/p2-repository/target/repository/">https://ci.eclipse.org/xpect/job/Xpect-Integration-Release/20/artifact/org.eclipse.xpect.releng/p2-repository/target/repository/</link></simpara>
-</listitem>
-</itemizedlist>
-<simpara>It is important to use the latest version of Xtext and the corresponding service release of Xcore. You will find the latest version numbers and plugins used in the target platform definition at
-<link xl:href="https://github.com/eclipse/n4js/blob/master/releng/org.eclipse.n4js.targetplatform/org.eclipse.n4js.targetplatform.target">https://github.com/eclipse/n4js/blob/master/releng/org.eclipse.n4js.targetplatform/org.eclipse.n4js.targetplatform.target</link></simpara>
-<simpara>You may need to adjust some settings in Eclipse, most importantly</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis role="strong">Text file encoding</emphasis> to <literal>Other: UTF-8</literal> and</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">New text file line delimiter</emphasis> to <literal>Unix</literal> .</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_release-engineering">
-<title>Release Engineering</title>
-<section xml:id="_nightly-build-on-eclipse-infrastructure">
-<title>Nightly build on Eclipse infrastructure</title>
-<simpara>The N4JS IDE, headless n4jsc.jar, and the N4JS update site is being built on the Eclipse Common Build
-Infrastructure (CBI). For this purpose the N4JS project is using a dedicated Jenkins instance, referred
-to as a "Jenkins Instance Per Project" (JIPP) in Eclipse CBI documentation. At this time, the N4JS
-project’s JIPP is running on the "old" infrastructure, not yet using docker. This will be migrated
-at a later point in time.</simpara>
-<simpara>The N4JS JIPP is available at: <link xl:href="https://ci.eclipse.org/n4js/">https://ci.eclipse.org/n4js/</link></simpara>
-<simpara>The nightly build performs the following main steps:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>compile the N4JS implementation,</simpara>
-</listitem>
-<listitem>
-<simpara>build the n4jsc.jar, the IDE products for MacOS, Windows, Linux, and the update site,</simpara>
-</listitem>
-<listitem>
-<simpara>run tests,</simpara>
-</listitem>
-<listitem>
-<simpara>sign the IDE product for macOS and package it in a .dmg file,</simpara>
-</listitem>
-<listitem>
-<simpara>deploy to n4jsc.jar, IDE products and update sites to Eclipse download server (i.e. download.eclipse.org),</simpara>
-</listitem>
-<listitem>
-<simpara>move all artifacts older than 7 days from download.eclipse.org to archive.eclipse.org.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Details about all the above steps can be found in the Jenkinsfile <literal>eclipse-nightly.jenkinsfile</literal>, located in
-the root folder of the N4JS source repository on GitHub.</simpara>
-<simpara>The most accurate documentation for our JIPP can be found at <link xl:href="https://wiki.eclipse.org/IT_Infrastructure_Doc">https://wiki.eclipse.org/IT_Infrastructure_Doc</link>.
-Note that many other documents do not apply to our JIPP, at the moment, as they refer to the new
-infrastructure, e.g. <link xl:href="https://wiki.eclipse.org/CBI">https://wiki.eclipse.org/CBI</link> and <link xl:href="https://wiki.eclipse.org/Jenkins">https://wiki.eclipse.org/Jenkins</link>.</simpara>
-</section>
-<section xml:id="_build-the-n4js-ide-from-command-line">
-<title>Build the N4JS IDE from command line</title>
-<simpara>Ensure you have</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Java 11</simpara>
-</listitem>
-<listitem>
-<simpara>Maven 3.2.x and</simpara>
-</listitem>
-<listitem>
-<simpara>Node.js 8</simpara>
-</listitem>
-</itemizedlist>
-<simpara>installed on your system.</simpara>
-<simpara>Clone the repository</simpara>
-<screen>git clone https://github.com/Eclipse/n4js.git</screen>
-<simpara>Change to the n4js folder:</simpara>
-<screen>cd n4js</screen>
-<simpara>Run the Maven build:</simpara>
-<screen>mvn clean verify</screen>
-<simpara>You may have to increase the memory for maven via <literal>export MAVEN_OPTS="-Xmx2048m"</literal> (Unix) or <literal>set MAVEN_OPTS="-Xmx2048m"</literal> (Windows).</simpara>
-<simpara>Available optional maven profiles are:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>buildProduct</simpara>
-</entry>
-<entry>
-<simpara>create IDE products (Windows, macOS, Linux) and a jar for headless compilation</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>execute-plugin-tests</simpara>
-</entry>
-<entry>
-<simpara>run OSGi tests (without UI)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>execute-plugin-ui-tests</simpara>
-</entry>
-<entry>
-<simpara>run UI-based OSGi tests</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>execute-ecmas-tests</simpara>
-</entry>
-<entry>
-<simpara>run ECMA test suite</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>execute-smoke-tests</simpara>
-</entry>
-<entry>
-<simpara>run generated tests using corrupted source code as input</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>execute-accesscontrol-tests</simpara>
-</entry>
-<entry>
-<simpara>run generated tests for checking accessibility of class/interface members</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>execute-hlc-integration-tests</simpara>
-</entry>
-<entry>
-<simpara>run integration tests using the headless jar (requires docker!)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Available system properties:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>noTests</simpara>
-</entry>
-<entry>
-<simpara>suppress execution of all tests</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>startAndKeepVerdaccio</simpara>
-</entry>
-<entry>
-<simpara>enforce starting and suppress stopping of the test verdaccio (see <xref linkend="sec:test-verdaccio"/>)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<section xml:id="_publish-maven-tooling-literal-org-eclipse-n4js-releng-util-literal">
-<title>Publish maven-tooling <literal>org.eclipse.n4js.releng.util</literal></title>
-<note>
-<simpara>For extending the N4JS-language in a different project, the <literal>org.eclipse.n4js.releng.util</literal> module needs to be published as a maven-plugin. You can deploy this SNAPSHOT-artifact to a local folder by providing the <literal>local-snapshot-deploy-folder</literal>-property pointing to an absolute path in the local file system:</simpara>
-</note>
-<screen>mvn clean deploy -Dlocal-snapshot-deploy-folder=/var/lib/my/folder/local-mvn-deploy-repository</screen>
-<simpara>The existence of <literal>local-snapshot-deploy-folder</literal> will trigger a profile enabling the deploy-goal for the project <literal>org.eclipse.n4js.releng.util</literal></simpara>
-</section>
-<section xml:id="sec:test-verdaccio">
-<title>Test Verdaccio containing n4js-libs</title>
-<simpara>If profile <literal>execute-hlc-integration-tests</literal> is active, a local verdaccio instance is started and populated with
-freshly-compiled n4js-libs (the libraries located under top-level folder <literal>/n4js-libs</literal>) and is stopped before the
-end of the build. The verdaccio instance is started as a docker container called <literal>n4js-test-verdaccio</literal>.</simpara>
-<simpara>When giving <literal>-DstartAndKeepVerdaccio</literal> on the command line, such a test verdaccio will always be started/populated but
-never stopped, regardless of whether profile <literal>execute-hlc-integration-tests</literal> is active or not. This is useful to enforce
-starting of the test verdaccio (even without running integration tests) and then reusing it in subsequent builds.</simpara>
-</section>
-<section xml:id="_generation-of-eclipse-help-for-spec-and-design-document">
-<title>Generation of Eclipse help for spec and design document</title>
-<simpara>The HTML pages for N4JSSpec and N4JSDesign documents are generated from the Asciidoc sources in the project <literal>org.eclipse.n4js.spec</literal> <literal>org.eclipse.n4js.design</literal> by Asciispec. </simpara>
-<figure xml:id="img:eclipse-help-doc-process">
-<title>The process of creating Eclipse help for N4JSSpec</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/03_releng/images/eclipse-help-process.svg"/>
-</imageobject>
-<textobject><phrase>Creating Eclipse help for N4JSSpec</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Figure <xref linkend="img:eclipse-help-doc-process"/> shows the generation process for N4JSSpec document. The process for N4JSDesign (and other adoc documents) is the same. The following explains the diagram.</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>Asciispec</literal> is used to compile the source N4JSSpec Asciidoc into a single large <literal>N4JSSpec.html</literal> file which contains all the chapters. The use of the custom parameter <literal>-a eclipse-help-mode</literal> indicates that a special header and footer styles as well as CSS style should be used (i.e. no table of content menu, no download links etc.). Here, we are using the possibility provided by Asciidoctor to configure header/footer as well as CSS style via parameter <literal>:docinfodir:</literal> and <literal>:stylesheet:</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Our custom tool <literal>Chunker</literal> splits <literal>N4JSSpec.html</literal> (and other documents) into multiple chunked HTML files, each of which corresponds to either the <literal>index</literal> file or a chapter. It automatically re-writes internal links.</simpara>
-</listitem>
-<listitem>
-<simpara>Another custom tool <literal>EclipseHelpTOCGenerator</literal> takes to Docbook file <literal>N4JSSpec.xml</literal> and generates an XML file describing the table of content (TOC) in the Eclipse format. This TOC file references the chunked HTML files above.</simpara>
-</listitem>
-<listitem>
-<simpara>Another custom tool <literal>IndexTocGenerator</literal> takes to Docbook file <literal>N4JSSpec.xml</literal> similar to <literal>EclipseHelpTOCGenerator</literal>, but it generates an HTML fragment which can be embedded into the <literal>index.html</literal> page generated by the <literal>Chunker</literal> (Thus it has to run before the Chunker in that case).</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-<section xml:id="_updating-frameworks-and-dependencies">
-<title>Updating frameworks and dependencies</title>
-<section xml:id="_update-of-eclipse-emf-xtext-etc">
-<title>Update of Eclipse, EMF, Xtext, etc.</title>
-<simpara>For updating the N4JS IDE to a new version of Eclipse, EMF, Xtext, etc. follow these steps:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Create a new branch.</simpara>
-</listitem>
-<listitem>
-<simpara>Bump versions of all dependencies mentioned in file <literal>N4JS.setup</literal>:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>Update all labels that refer to the version of the Ooomph setup (search for "label!" to find them).</simpara>
-</listitem>
-<listitem>
-<simpara>Choose a new Eclipse version and define this in <literal>N4JS.setup</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>For those other dependencies <emphasis>that come with Eclipse</emphasis> (e.g. EMF, Xtext) find out which version matches the chosen Eclipse version
-and define that version in <literal>N4JS.setup</literal>.<?asciidoc-br?>
-Tip: use the contents list of the SimRel you are targeting, e.g. <link xl:href="https://projects.eclipse.org/releases/2019-03">https://projects.eclipse.org/releases/2019-03</link></simpara>
-</listitem>
-<listitem>
-<simpara>For those other dependencies <emphasis>that are available via the Eclipse Orbit</emphasis>, find out which version is the latest version available in
-the Orbit and define that version in <literal>N4JS.setup</literal>.<?asciidoc-br?>
-Tip: contents of the Eclipse Orbit can be found at <link xl:href="https://download.eclipse.org/tools/orbit/downloads/">https://download.eclipse.org/tools/orbit/downloads/</link><?asciidoc-br?>
-(choose the correct link for the chosen Eclipse version!)</simpara>
-</listitem>
-<listitem>
-<simpara>For all remaining dependencies (i.e. unrelated to Eclipse and not in Orbit), choose a version to use and define it in <literal>N4JS.setup</literal>.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Check <literal>Require-Bundle</literal> sections of MANIFEST.MF files by searching for related bundle names or for <literal>;bundle-version="</literal>:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>There should be at most one version constraint for a specific bundle<?asciidoc-br?>
-NOTE: the version constraints in the MANIFEST.MF files are just lower bounds and - at this time - we do not bump them to the latest version, in most cases.</simpara>
-</listitem>
-<listitem>
-<simpara>There should be no version constraints to our bundles (i.e. <literal>org.eclipse.n4js…​</literal>)</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Review parent pom.xml files, i.e. <literal>releng/org.eclipse.n4js.parent/pom.xml</literal>:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>Update property <literal>xtext-version</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Check all other <literal>*-version</literal> properties and update them where needed.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Update target platform file <literal>org.eclipse.n4js.targetplatform.target</literal> using Ooomph’s auto-generation:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>Start the Eclipse Installer.</simpara>
-</listitem>
-<listitem>
-<simpara>Update the Eclipse Installer (using the button with the turning arrows).</simpara>
-</listitem>
-<listitem>
-<simpara>On the second page, add the <literal>N4JS.setup</literal> file from your branch to the Eclipse Installer, using a GitHub raw(!) URL:<?asciidoc-br?>
-<literal><link xl:href="https://raw.githubusercontent.com/eclipse/n4js/BRANCH_NAME/releng/org.eclipse.n4js.targetplatform/N4JS.setup">https://raw.githubusercontent.com/eclipse/n4js/BRANCH_NAME/releng/org.eclipse.n4js.targetplatform/N4JS.setup</link></literal></simpara>
-</listitem>
-<listitem>
-<simpara>Ooomph a new development environment with this setup.</simpara>
-</listitem>
-<listitem>
-<simpara>In the new Eclipse workspace created by Ooomph, the target platform file should have uncommitted changes:</simpara>
-<orderedlist numeration="lowerroman">
-<listitem>
-<simpara>carefully review these changes, to be sure they make sense, and then</simpara>
-</listitem>
-<listitem>
-<simpara>commit & push those changes to your branch.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Thoroughly test the new versions, including some manual(!) tests:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>Run Jenkins builds.</simpara>
-</listitem>
-<listitem>
-<simpara>Ooomph another N4JS development environment with Eclipse Installer.
-This time, after Ooomphing is completed, the target platform file should no longer have any uncommitted changes.</simpara>
-</listitem>
-<listitem>
-<simpara>Ensure the following types of tests can be executed locally in the newly installed Eclipse:</simpara>
-<orderedlist numeration="lowerroman">
-<listitem>
-<simpara>plain JUnit tests (e.g. <literal>org.eclipse.n4js.lang.tests</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>Plugin tests.</simpara>
-</listitem>
-<listitem>
-<simpara>Plugin UI tests.</simpara>
-</listitem>
-<listitem>
-<simpara>SWTBot tests.</simpara>
-</listitem>
-<listitem>
-<simpara>Xpect tests (individual files and entire bundles; e.g. <literal>org.eclipse.n4js.spec.tests</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>Xpect UI tests.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Ensure an N4JS IDE product can be launched from within the newly installed Eclipse using the launch configuration
-provided in the n4js repository.</simpara>
-</listitem>
-<listitem>
-<simpara>After launching the N4JS IDE product, refresh the workspace and review/commit any changes in file <literal>N4JS__IDE.launch</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Download a product created in a Jenkins CI build and test it manually.</simpara>
-</listitem>
-<listitem>
-<simpara>After merging to master: download a product created in a nightly build and test it manually.
-Ensure signing and JRE bundling are still working properly.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-<simpara>All the above steps need to be performed in the <literal>n4js-n4</literal> repository, accordingly (e.g. file <literal>N4JS-N4.setup</literal>).</simpara>
-</section>
-<section xml:id="_update-of-the-embedded-jre">
-<title>Update of the embedded JRE</title>
-<simpara>For updating the embedded JRE inside the N4JS IDE follow these steps:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Given a new JRE download location for Linux, MacOS and Windows with a common new version</simpara>
-</listitem>
-<listitem>
-<simpara>Update the location related properties in the pom.xml files of</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>n4js/builds/pom.xml</simpara>
-</listitem>
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.linux.gtk.x86_64/pom.xml</simpara>
-</listitem>
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.macosx.cocoa.x86_64/pom.xml</simpara>
-</listitem>
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.win32.win32.x86_64/pom.xml</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Update the versions at all following locations:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.linux.gtk.x86_64/META-INF/MANIFEST.MF</simpara>
-</listitem>
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.linux.gtk.x86_64/META-INF/p2.inf</simpara>
-</listitem>
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.macosx.cocoa.x86_64/META-INF/MANIFEST.MF</simpara>
-</listitem>
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.macosx.cocoa.x86_64/META-INF/p2.inf</simpara>
-</listitem>
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.win32.win32.x86_64/META-INF/MANIFEST.MF</simpara>
-</listitem>
-<listitem>
-<simpara>n4js/builds/org.eclipse.n4js.jre.win32.win32.x86_64/META-INF/p2.inf</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Update the openjdk docker image used as base image in the "FROM" line at the top of all docker files:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>n4js-n4/jenkins/docker-build/Dockerfile</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_tips-and-tricks">
-<title>Tips and Tricks</title>
-<simpara>In this chapter we collect some coding hints and guidelines on how to properly use the APIs of Eclipse, EMF, Xtext and
-other dependencies we are using, as well as our own utilities and helpers.</simpara>
-<simpara>This chapter is only about coding; add information on things like Eclipse setup or Maven/Jenkins to one of the preceding
-chapters. Similarly, this chapter is intended to provide just a quick overview, check-list and reminder; add detailed
-information and diagrams to one of the succeeding chapters.</simpara>
-<section xml:id="_naming">
-<title>Naming</title>
-<itemizedlist>
-<listitem>
-<simpara>The internal handling of N4JS project names is non-trivial (due to the support for npm scopes), see
-API documentation of <literal>ProjectDescriptionUtils#isProjectNameWithScope(String)</literal> for a detailed overview.
-In short:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>IN4JSProject#getProjectName()</literal> and <literal>IProject#getName()</literal> return different values!</simpara>
-</listitem>
-<listitem>
-<simpara>Avoid using the Eclipse project name, i.e. the return value of <literal>IProject#getName()</literal>, as far as possible
-(only use it in UI code when actually dealing with what is shown in the Eclipse UI).</simpara>
-</listitem>
-<listitem>
-<simpara>The last segment of an URI or path pointing to an N4JS project is <emphasis role="strong">not</emphasis> always the project name; use
-utilities in <literal>ProjectDescriptionUtils</literal> instead, e.g. <literal>#deriveN4JSProjectNameFromURI()</literal>!
-(However, given an URI or path pointing to a file inside an N4JS project, you can use its last segment
-to obtain the file name.)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_logging">
-<title>Logging</title>
-<simpara>In many situations developer needs to use some kind of logging. When in need, follow these rules:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Use <literal>org.apache.log4j.Logger;</literal> for logging. Other logging utilities (like java built in logger) are not configured.</simpara>
-</listitem>
-<listitem>
-<simpara>do not use <literal>System.out</literal> nor <literal>Sysetem.err</literal> for logging. It is ok to use it for debugging purposes, but those calls
-should never be merged to master. <emphasis>(with exception of headless compiler, which uses them explicitly)</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara>There is central logger configuration in <literal>org.eclipse.n4js.utils.logging</literal> (and <literal>org.eclipse.n4js.utils.logging</literal>) that should
-be used</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara><literal>log4j.xml</literal> used for production</simpara>
-</listitem>
-<listitem>
-<simpara><literal>log4j_tests.xml</literal> used when running tests</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>in Eclipse run configurations logger has to be set properly, e.g.
-<literal>log4j.configuration=file:${workspace_loc:org.eclipse.n4js.utils.logging/log4j_tests.xml}</literal></simpara>
-</listitem>
-<listitem>
-<simpara>in maven configurations logger has to be set separately, e.g.
-<literal>-Dlog4j.configuration="file:${basedir}/../../plugins/org.eclipse.n4js.utils.logging/log4j_tests.xml</literal></simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="_cancellation-handling">
-<title>Cancellation Handling</title>
-<simpara>At various occasions, Xtext provides an instance of class <literal>CancelIndicator</literal> to allow our code to handle cancellation of
-long-running task.</simpara>
-<simpara>Some things to keep in mind:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>whenever a <literal>CancelIndicator</literal> is available any code that might not return immediately should implement proper
-cancellation handling (as explained in the next items).</simpara>
-</listitem>
-<listitem>
-<simpara>most importantly: reacting to a cancellation by returning early from a method is an anti-pattern that leads to
-problems (client code might continue work on a canceled and thus invalid state); instead: throw an
-<literal>OperationCanceledException</literal>!</simpara>
-</listitem>
-<listitem>
-<simpara>don’t use <literal>CancelIndicator#isCanceled()</literal> for cancellation handling, except in certain special cases. A valid exception
-case might be during logging to show a message like "operation was canceled".</simpara>
-</listitem>
-<listitem>
-<simpara>instead, inject the Xtext service called <literal>OperationCanceledManager</literal> and invoke its method <literal>#checkCanceled()</literal>, passing-in
-the cancel indicator (this method is null-safe; it will throw an <literal>OperationCanceledException</literal> in case a cancellation has
-occurred). Don’t directly create and throw an <literal>OperationCanceledException</literal> yourself.</simpara>
-</listitem>
-<listitem>
-<simpara>use the other methods provided by <literal>OperationCanceledManager</literal> when appropriate (see code of that class for details).</simpara>
-</listitem>
-<listitem>
-<simpara>in try/catch blocks, when catching exceptions of a super type of <literal>OperationCanceledException</literal>, be sure to <emphasis role="strong">not suppress</emphasis>
-cancellation exceptions. For example:</simpara>
-<programlisting language="java" linenumbering="unnumbered">// Java code
-@Inject private OperationCanceledManager operationCanceledManager;
-/** Returns true on success, false otherwise. */
-public boolean doSomething(CancelIndicator ci) {
- try {
- // do something that might be canceled
- return true;
- } catch(Exception e) {
- operationCanceledManager.propagateIfCancelException(e); // <- IMPORTANT!
- return false;
- }
-}</programlisting>
-<simpara>Try/finally blocks, on the other hand, do not need any special handling.</simpara>
-</listitem>
-<listitem>
-<simpara>a cancel indicator can also be stored in the rule environment (see <literal>RuleEnvironmentExtensions#addCancelIndicator()</literal>). This
-means:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>if you create a rule environment completely from scratch and you have a cancel indicator at hand, add it to the rule
-environment via <literal>RuleEnvironmentExtensions#addCancelIndicator()</literal> (not required when using <literal>RuleEnvironmentExtensions#wrap()</literal> for
-deriving a rule environment from an existing one).</simpara>
-</listitem>
-<listitem>
-<simpara>if you have a rule environment available, be sure to use its cancel indicator in long-running operations, i.e. with
-code like:</simpara>
-<programlisting language="java" linenumbering="unnumbered">// Xtend code
-import static extension org.eclipse.n4js.typesystem.utils.RuleEnvironmentExtensions.*
-class C {
- @Inject private OperationCanceledManager operationCanceledManager;
- def void doSomething() {
- for(a : aLotOfStuff) {
- operationCanceledManager.checkCanceled(G.cancelIndicator);
- // main work ...
- }
- }</programlisting>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_caching">
-<title>Caching</title>
-<itemizedlist>
-<listitem>
-<simpara>Caching of external libraries (implemented in ExternalProjectMappings)</simpara>
-<itemizedlist>
-<listitem>
-<simpara>update <emphasis>only</emphasis> using <literal>EclipseExternalLibraryWorkspace#updateState()</literal></simpara>
-</listitem>
-<listitem>
-<simpara>always mind that the diff of current state and cached state is a necessary information for cleaning dependencies of removed npms</simpara>
-<itemizedlist>
-<listitem>
-<simpara>see <literal>EclipseExternalIndexSynchronizer#synchronizeNpms()</literal> for implementation</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>updating also happens when external root locations change (see ExternalIndexUpdater)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Caching of user workspace projects (implemented in MuliCleartriggerCache)</simpara>
-<itemizedlist>
-<listitem>
-<simpara>caches only some project information and should be refactored along with Core, Model and EclipseBasedN4JSWorkspace</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_dependency-injection">
-<title>Dependency Injection</title>
-<simpara>There are some things to keep in mind when using dependency injection in the context of Xtext. This is a longer topic and it is discussed in the appendix
-<xref linkend="sec:XtextInjection"/>.</simpara>
-</section>
-<section xml:id="_miscellaneous">
-<title>Miscellaneous</title>
-<itemizedlist>
-<listitem>
-<simpara>Resource load states: when an N4JS/N4JSD file is loaded, a certain sequence of processing is triggered (parsing,
-linking, validation, etc.) and thus an <literal>N4JSResource</literal> transitions through a sequence of "load states". For details,
-see <xref linkend="sec:N4JS_Resource_Load_States"/>.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</chapter>
-<chapter xml:id="_parser">
-<title>Parser</title>
-<simpara>Some of the concepts described here were presented at
-<link xl:href="https://www.youtube.com/watch?v=Xm-7aE1UMGY&feature=youtu.be">EclipseCon 2013</link> and
-<link xl:href="https://vimeo.com/channels/xtextcon/98446435">XtextCon 2014</link>. Note that the material presented at the linked videos may be outdated.</simpara>
-<section xml:id="sec:Parser_Overview">
-<title>Overview</title>
-<simpara>The parser is created from an Xtext grammar. Actually, there are several grammars used as shown in <link linkend="fig:cd_grammars">Figure CD Grammars</link>. These grammars and the parsers generated from them are described more closely in the following sections.</simpara>
-<figure xml:id="fig:cd_grammars" role="center">
-<title>N4 Grammars</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/05_parser/images/cd_grammars.svg"/>
-</imageobject>
-<textobject><phrase>cd grammars</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:N4JS_Parser">
-<title>N4JS Parser</title>
-<simpara>One of the most tricky parts of JavaScript is the parsing because there is a conceptual mismatch between the <link linkend="AC">ANTLR</link> runtime and the specified grammar. Another challenge is the disambiguation of regular expressions and binary operations. Both features require significant customizing of the generated parser (see figure below).</simpara>
-<figure xml:id="fig:cd_ASIParser" role="center">
-<title>Overview custom parser implementation (runtime only)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/05_parser/images/cd_ASIParser.svg"/>
-</imageobject>
-<textobject><phrase>cd ASIParser</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:Parser_Generation_Post_Processing" role="language-bash">
-<title>Parser Generation Post-Processing</title>
-<simpara>The ANTLR grammar that is generated by Xtext is post-processed to inject custom code into the grammar file before it is passed to the ANTLR tool. This is required in particular due to <link linkend="AC">ASI</link> (Automated Semicolon Insertion), but for some other reasons as well.</simpara>
-<simpara>Actually, there are several injections:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Due to Xtext restrictions, the generated ANTLR grammar file (<emphasis role="strong">*.g</emphasis>) is modified. This means that some some additional actions are added and some rules are rewritten.</simpara>
-</listitem>
-<listitem>
-<simpara>Due to ANTLR restrictions, the generated ANTLR Java parser (<emphasis role="strong">*.java</emphasis>) os modified. This means that some generated rules are slightly modified to match certain requirements.</simpara>
-</listitem>
-<listitem>
-<simpara>Due to Java restrictions, the generated Java parser needs to be preprocessed in order to reduce the size of certain methods since they must not exceed 64k characters. This is implemented by means of an MWE fragment, activated after the other post processing steps are done.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The first two steps are handled by <literal>AntlrGeneratorWithCustomKeywordLogic</literal>, which is configured with additional helpers in <literal>GenerateN4JS.mwe2</literal>. shows the customized classes which modify the code generation. These classes are all part of the <literal>releng.utils</literal> bundle.</simpara>
-<figure role="center">
-<title>Class Diagram Parser Generation</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/05_parser/images/cd_parsergeneration.svg"/>
-</imageobject>
-<textobject><phrase>cd parsergeneration</phrase></textobject>
-</mediaobject>
-</figure>
-<section xml:id="sec:Automatic_Semicolon_Insertion">
-<title>Automatic Semicolon Insertion</title>
-<simpara>The EcmaScript specification mandates that valid implementations automatically insert a semicolon as a statement delimiter if it is missing and the input file would become invalid due to the missing semicolon. This is known as <link linkend="AC">ASI</link>. It implies that not only valid implementations have to perform this, but a valid parser has to mimic this behavior in order to parse executable code. The <link linkend="AC">ASI</link> is implemented by two different means.</simpara>
-<simpara>The parser’s error recovery strategy is customized so it attempts to insert a semicolon if it was expected. Both strategies have to work hand in hand in order to consume all sorts of legal JavaScript code.</simpara>
-<section xml:id="sec:Injected_code_in_the_Antlr_grammar_file">
-<title>Injected code in the Antlr grammar file</title>
-<simpara>Under certain circumstances, the parser has to actively promote a token to become a semicolon even though it may be a syntactically a closing brace or line break. This has to happen before that token is consumed thus the rules for return statements, continue statements and break statements are enhanced to actively promote these tokens to semicolons.</simpara>
-<simpara>The same rule is applied to promote line breaks between an expression and a possible postfix operator <literal>++</literal> or <literal>–</literal>. At this location the line break is always treated as a semicolon even though the operator may be validly consumed and produce a postfix expression.</simpara>
-<simpara>In both cases, the method <literal>promoteEOL()</literal> is used to move a token that may serve as an automatically injected semicolon from the so called hidden token channel to the semantic channel. The hidden tokens are usually not handled by the parser explicitly thus they are semantically invisible (therefore the term hidden token). Nevertheless, they can be put on the semantic channel explicitly to make them recognizable. That’s implemented in the EOL promotion. The offending tokens include the hidden line terminators and multi-line comments that include line breaks. Furthermore, closing braces (right curly brackets) are included in the set of offending tokens as well as explicit semicolons.</simpara>
-</section>
-<section xml:id="sec:Customized_error_recovery">
-<title>Customized error recovery</title>
-<simpara>Since the EOL promotion does not work well with Antlr prediction mode, another customization complements that feature. As soon as an invalid token sequence is attempted to be parsed and missing semicolon would make that sequence valid, an offending token is sought and moved to the semantic channel. This is implemented in the custom recovery strategy.</simpara>
-</section>
-</section>
-<section xml:id="sec:_No_line_terminator_allowed_here__handling">
-<title>Async and <literal>No line terminator allowed here</literal> Handling</title>
-<simpara>There is no way of directly defining <literal>No line terminator allowed here</literal>. This is required not only for <link linkend="AC">ASI</link>, but also for <literal>async</literal>. This requires not only a special rule (using some rules from <link linkend="sec:Automatic_Semicolon_Insertion">ASI</link>), but also a special error recovery since the token ’async’ may be rejected (by the manually enriched rule) which is of course unexpected behavior from the generated source code.</simpara>
-</section>
-<section xml:id="sec:Regular_Expression">
-<title>Regular Expression</title>
-<simpara>The ANTLR parsing process can basically be divided into three steps. First of all, the file contents has to be read from disk. This includes the proper encoding of bytes to characters. The second step is the lexing or tokenizing of the character stream. A token is a basically a typed region in the stream, that is a triplet of token-id, offset and length. The last step is the parsing of these tokens. The result is a semantic model that is associated with a node tree. All necessary information to validate the model can be deduced from these two interlinked representations.</simpara>
-<figure role="center">
-<title>Simplified visualization of the parsing</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/05_parser/images/ad_parsing_simplified.svg"/>
-</imageobject>
-<textobject><phrase>ad parsing simplified</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Since the default semantics and control flow of Antlr generated parsers do not really fit the requirements of a fully working JavaScript parser, some customizations are necessary. <emphasis role="strong">Regular expression literals in JavaScript cannot be syntactically disambiguated from div operations without contextual information.</emphasis> Nevertheless, the spec clearly describes, where a regular expression may appear and where it is prohibited. Unfortunately, it is not possible to implement these rules in the lexer alone, since it does not have enough contextual information. Therefore, the parser has been enhanced to establish a communication channel with the lexer. It announces when it expects a regular expression rather than a binary operation.</simpara>
-<simpara>This required a reworking of the Antlr internals. Instead of a completely pre-populated <literal>TokenStream</literal>, the parser works on a lazy implementation that only reads as many characters as possible without a disambiguation between regular expression literals and divide operators.</simpara>
-<simpara>Only after the parser has read this buffered tokens and potentially announced that it expects a regular expression, another batch of characters is processed by the lexer until the next ambiguous situation occurs. This is fundamentally different from the default behavior of Antlr.</simpara>
-<figure role="center">
-<title>Abstract control and object flow during parsing</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/05_parser/images/sd_parsing_sequence.svg"/>
-</imageobject>
-<textobject><phrase>sd parsing sequence</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>shows the involved classes which allow for this lexer-parser communication.</simpara>
-<figure role="center">
-<title>Class Diagram Parser-Lexer Communication</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/05_parser/images/cd_parserlexercommunication.svg"/>
-</imageobject>
-<textobject><phrase>cd parserlexercommunication</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:Unicode">
-<title>Unicode</title>
-<simpara>Unicode support in JavaScript includes the possibility to use unicode escape sequences in identifiers, string literals and regular expression literals. Another issue in this field is the specification of valid identifiers in JavaScript. They are described by means of unicode character classes. These have to be enumerated in the terminal rules in order to fully accept or reject valid or invalid JS identifiers.</simpara>
-<simpara>For that purpose, a small code generator is used to define the terminal fragments for certain unicode categories. The <literal>UnicodeGrammarGenerator</literal> basically iterates all characters from <literal>Character.MIN_VALUE</literal> to <literal>Character.MAX_VALUE</literal> and adds them as alternatives to the respective terminal fragments, e.g. <literal>UNICODE_DIGIT_FRAGMENT</literal>.</simpara>
-<simpara>The real terminal rules are defined as a composition of these generated fragments. Besides that, each character in an identifier, in a string literal or in a regular expression literal may be represented by its unicode escape value, e.g. ` u0060`. These escape sequences are handled and validated by the <literal>IValueConverter</literal> for the corresponding terminal rules.</simpara>
-<simpara>The second piece of the puzzle are the unicode escaped sequences that may be used in keywords. This issue is covered by the <literal>UnicodeKeywordHelper</literal> which replaces the default terminal representation in the generated Antlr grammar by more elaborated alternatives. The keyword <literal>if</literal> is not only lexed as <literal>’if’</literal> but as seen in snippet
-<link linkend="lst:terminal_if">Terminal if listing</link>.</simpara>
-<formalpara xml:id="lst:terminal_if">
-<title>Terminal if</title>
-<para>
-<screen>If :
- ( 'i' | '\\' 'u' '0`` 0`` 6`` 9' )
- ( 'f' | '\\' 'u' '0`` 0`` 6`` 6' );</screen>
-</para>
-</formalpara>
-</section>
-<section xml:id="sec:Literals">
-<title>Literals</title>
-<simpara>Template literals are also to be handled specially, see <literal>TemplateLiteralDisambiguationInjector</literal> for details.</simpara>
-</section>
-</section>
-<section xml:id="sec:Modifiers" role="language-n4js">
-<title>Modifiers</title>
-<simpara>On the AST side, all modifiers are included in a single enumeration <literal>N4Modifier</literal>. In the types model however, the individual modifiers are mapped to two different enumerations of <emphasis>access</emphasis> modifiers (namely <literal>TypeAccessModifier</literal> and <literal>MemberAccessModifier</literal>) and a number of boolean properties (in case of non-access modifiers such as <literal>abstract</literal> or <literal>static</literal>). This mapping is done by the types builder, mostly by calling methods in class <literal>ModifierUtils</literal>.</simpara>
-<simpara>The grammar allows the use of certain modifiers in many places that are actually invalid. Rules where a certain modifier may appear in the AST are implemented in method isValid(EClass,N4Modifier) in class <literal>ModifierUtils</literal> and checked via several validations in <literal>N4JSSyntaxValidator</literal>. Those validations also check for a particular order of modifiers that is not enforced by the grammar.</simpara>
-<simpara>See API documentation of enumeration <literal>N4Modifier</literal> in file <literal>N4JS.xcore</literal> and the utility class <literal>ModifierUtils</literal> for more details.</simpara>
-</section>
-<section xml:id="sec:Conflict_Resolutions" role="language-n4js">
-<title>Conflict Resolutions</title>
-<section xml:id="sec:Reserved_Keywords_vs__Identifier_Names">
-<title>Reserved Keywords vs. Identifier Names</title>
-<simpara>Keywords and identifiers have to be distinguished by the lexer. Therefore, there is no means to decide upfront whether a certain keyword is actually used as a keyword or whether it is used as an identifier in a given context. This limitation is idiomatically overcome by a data type rule for valid identifiers. This data type rule enumerates all keywords which may be used as identifiers and the pure IDENTIFIER terminal rule as seen in <link linkend="lst:keywords_as_identifier">Keywords as Identifier listing</link>.</simpara>
-<formalpara xml:id="lst:keywords_as_identifier">
-<title>Keywords as Identifier</title>
-<para>
-<programlisting language="ebnf" linenumbering="unnumbered">N4JSIdentifier: IDENTIFIER
- | 'get'
- | 'set'
- ...
-;</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="sec:Operators_and_Generics">
-<title>Operators and Generics</title>
-<simpara>The ambiguity between shift operators and nested generics arises also from the fact, that Antlr lexer upfront without any contextual information. When implemented naively, the grammar will be broken, since a token sequence <literal>a>>b</literal> can either be part of <literal>List<List<a>> b</literal> or it can be part of a binary operation <literal>int c = a >> b</literal>. Therefore the shift operator may not be defined with a single token but has to be composed from individual characters (see <link linkend="lst:shift_operator">Shift Operator listing</link>).</simpara>
-<formalpara xml:id="lst:shift_operator">
-<title>Shift Operator listing</title>
-<para>
-<programlisting language="ebnf" linenumbering="unnumbered">ShiftOperator:
- '>' '>' '>'?
- | '<' '<'
- ;</programlisting>
-</para>
-</formalpara>
-</section>
-</section>
-<section xml:id="sec:Content_Assist_Parser" role="language-n4js">
-<title>Content-Assist Parser</title>
-<warning>
-<simpara>This section may be outdated!</simpara>
-</warning>
-<simpara>The <link linkend="AC">CA</link> parser also needs adjustments for supporting automatic semicolon insertion and regular expressions. Instead of modifying the <link linkend="AC">CA</link> parser generator similar to the normal parser, the former reuses parts of the latter as far as possible. That is, the token sequence that is produced during production parsing is used as is for the content assist parser. Semicolons have already been inserted where appropriate and regular expression are successfully distinguished from divide operators.</simpara>
-<simpara>Since the n4js grammar uses syntactic predicates, the content assist parser is compiled with backtracking enabled. This is always the case for Xtext’s CA parsers that rely on backtracking or predicates (local backtracking) in the production parser. This approach is both good (CA works in general) and bad (unpredictable decisions in case of error at locations prior to the cursor). Since parsing with backtracking enabled makes for a fundamental difference in how the prediction and parsing works and how the parser decides which decision paths to take, the customization patterns from the production parser are not applied 1:1 to the CA parser, but adapted instead. The content assist parser doesn’t use a freshly lexed token stream with unicode support, ASI or regular expression literals, but instead uses a synthesized token sequence which is rebuilt from the existing node model.</simpara>
-<simpara>The token stream that is consumed by the content assist parser is therefore not created by a lexer but by the <literal>org.eclipse.n4js.ui.contentassist.NodeModelTokenSource</literal>.
-It traverses the existing node model that is contained in the resource and was produced by the production parser. This approach has the significant advantage that any decision that was made by that parser is also immediately applicable to the content assist infrastructure. For that purpose, the leaf nodes of the node model are mapped to ANTLR token types.
-This is achieved by the <literal>org.eclipse.n4js.ui.contentassist.ContentAssistTokenTypeMapper</literal> which is capable to provide the untyped ANTLR token type (primitive int) for a given grammar element.</simpara>
-<simpara>Special considerations have been made for the last token in the produced source. If it overlaps with an existing leaf node but does not fully cover it, the plain Antlr lexer is used to consume the prefix that is overlapping. Since the terminals will never overlap with each other the longest match always wins without backtracking in the lexer, it is save to assume that only one token is produced from the prefix. The very last token in the <literal>org.eclipse.n4js.ui.contentassist.NodeModelTokenSource</literal> is always the EOF token (<literal>org.antlr.runtime.Token.EOF_TOKEN</literal>).</simpara>
-<simpara>Given that the token source is equal to the prefix in the production token source, some more thought has to be put into the synthesized end of file. The production parser used the complete file to decide where to automatically insert a semicolon and where not to. This would potentially change if there was another token next to the artificial EOF. Therefore, two cases have to considered. The first one describes CA request next to an automatically inserted semicolon and the second one describes CA requests at a position where a semicolon could have been inserted if the token to the right was another one. The <literal>org.eclipse.n4js.ui.contentassist.CustomN4JSParser</literal> reflects these cases. Heuristics are applied to the end of the token sequence to decide whether a second pass has to be performed to collect yet more following elements. Based on the concrete sequence, the last automatically inserted semicolon is removed from the sequence prior to the second pass or such is a token is explicitly synthesized and appended. Besides the second pass, another special treatment is made for postfix expressions. Those may not be interrupted by a hidden semicolon so those are filtered from the resulting follow set if appropriate.</simpara>
-<simpara>The parser is used by the <literal>org.eclipse.n4js.ui.contentassist.ContentAssistContextFactory</literal> where all relevant entry points from the super class are specialized to pass the node model in the the parser facade (<literal>org.eclipse.n4js.ui.contentassist.CustomN4JSParser</literal>). In that sense, the ContentAssistContextFactory serves as a drop-in replacement binding the default <literal>ParserBasedContentAssistContextFactory.StatefulFactory</literal>.</simpara>
-</section>
-</chapter>
-<chapter xml:id="_type-system">
-<title>Type System</title>
-<section xml:id="sec:Type_Model_and_Grammar" role="language-n4js">
-<title>Type Model and Grammar</title>
-<simpara>The type model is used to define actual types and their relations (meta-model is defined by means of Xcore in file <literal>Types.xcore</literal>)
-and also references to types (meta-model in <literal>TypeRefs.xcore</literal>). The type model is built via the <literal>N4JSTypesBuilder</literal> when a resource
-is loaded and processed, and most type related tasks work only on the type model. Some types that are (internally) available
-in N4JS are not defined in N4JS, but instead in a special, internal type language not available to N4JS developers, called N4TS
-and defined in file <literal>Types.xtext</literal>.</simpara>
-<simpara>The types are referenced by AST elements; vice versa the AST elements can be referenced from the types (see <literal>SyntaxRelatedTElement</literal>).
-This backward reference is a simple reference to an EObject.</simpara>
-<section xml:id="sec:Type_Model_Overview">
-<title>Type Model Overview</title>
-<simpara>The following figure, <link linkend="fig:cd_typeAndTypeRefHierarchy">Types and Type References</link>, shows the classes of the type model and their inheritance relations, both the actual type definitions as defined in <literal>Types.xcore</literal> and the type references defined in <literal>TypeRefs.xcore</literal>. The most important type reference is the <literal>ParameterizedTypeRef</literal>; it is used for most user-defined references, for both parameterized and non-parameterized references. In the latter case, the list of type arguments is empty.</simpara>
-<figure xml:id="fig:cd_typeAndTypeRefHierarchy">
-<title>Type Model Overview: Types in the upper half and Type References in the lower half.</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/06_typesystem/images/cd_typeModelHierarchy_allInOne.png"/>
-</imageobject>
-<textobject><phrase>cd typeModelHierarchy allInOne</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Most types are self-explanatory. <literal>TypeDefs</literal> is the container element used in N4TS. Note that not all types and properties of types are available in N4JS – some can only be used in the N4TS language or be inferred by the type system for internal purposes. Some types need some explanation:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>TObjectPrototype</literal>: Metatype for defining built-in object types such as <literal>Object</literal> or <literal>Date</literal>, only available in N4TS.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>VirtualBaseType</literal>: This type is not available in N4JS. It is used to define common properties provided by all types of a certain metatype. E.g., it is used for defining some properties shared by all enumerations (this was the reason for introducing this type).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>We distinguish four kinds of types as summarized in <link linkend="tab:KindOfTypes">Kind Of Types</link>. Role is an internal construct for different kind of users who can define the special kind of type. The language column refers to the language used to specify the type; which is either N4JS or N4TS.</simpara>
-<table xml:id="tab:KindOfTypes" frame="all" rowsep="1" colsep="1">
-<title>Kind of Types</title>
-<tgroup cols="4">
-<colspec colname="col_1" colwidth="10*"/>
-<colspec colname="col_2" colwidth="10*"/>
-<colspec colname="col_3" colwidth="10*"/>
-<colspec colname="col_4" colwidth="70*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Kind</entry>
-<entry align="left" valign="top">Language</entry>
-<entry align="left" valign="top">Role</entry>
-<entry align="left" valign="top">Remark</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">user</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4JS</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">developer</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>User defined types, such as declared classes or functions. These types are to be explicitly defined or imported in the code.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">library</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4JSD</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">developer</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Type declarations only, comparable to C header files, without implementation. Used for defining the API of 3rd party libraries. These type definitions are to be explicitly defined or imported in the code.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">builtin</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4TS</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">smith</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Built-in ECMAScript objects interpreted as types. E.g., <literal>String</literal>, <literal>Date</literal>, <literal>Math</literal>. These types are provided by N4JS and are always available.</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">primitive</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4TS</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">smith</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>Primitive ECMAScript (and N4JS ties), such as <literal>string</literal>, <literal>number</literal>, <literal>pathselector<T></literal>, <literal>i18n</literal>, and also <literal>any</literal>, <literal>undefined</literal> and <literal>void</literal>. These types are provided by N4JS and are always available. Primitive types are described in detail in the spec (see chapter "Primitive ECMAScript Types").</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-</section>
-<section xml:id="sec:Built_in_Types">
-<title>Built-in and Primitive Types</title>
-<simpara>The built-in and primitive types are not defined by the user, i.e. N4JS programmer. Instead, they are defined in special
-internal files using the internal N4TS language: <literal>builtin_js.n4ts</literal>, <literal>builtin_n4.n4ts</literal>, <literal>primitives_js.n4ts</literal>, <literal>primitives_n4.n4ts</literal>.</simpara>
-</section>
-<section xml:id="sec:Type_Model_DSL" role="language-n4js">
-<title>Type Model DSL</title>
-<simpara>For defining built-in types and for tests, a special DSL called N4TS is provided by means of an Xtext grammar and generated
-tools. The syntax is similar to n4js, but of course without method or function bodies, i.e. without any statements of expressions.
-The grammar file is found in <literal>Types.xtext</literal>.</simpara>
-<simpara>The following list documents some differences to N4JS:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>access modifiers directly support <literal>Internal</literal>, so no annotations are needed (nor supported) here.</simpara>
-</listitem>
-<listitem>
-<simpara>besides N4 classifiers such as classes, the following classifiers can be defined:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara><literal>object</literal> define classes derived from object (predefined object types) Special features:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>indexed</simpara>
-</entry>
-<entry>
-<simpara>defined what type is returned in case of index access</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-<listitem>
-<simpara><literal>virtualBase</literal> virtual base types for argument</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara><literal>primitive</literal> primitive types (number, string etc.) Special features:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>indexed</simpara>
-</entry>
-<entry>
-<simpara>defined what type is returned in case of index access</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>autoboxedType</simpara>
-</entry>
-<entry>
-<simpara>defines to which type the primitive can be auto boxed</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>assignmnentCompatible</simpara>
-</entry>
-<entry>
-<simpara>defines to which type the primitive is assignment compatible</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-<listitem>
-<simpara>types <literal>any</literal>, <literal>null</literal>, <literal>void</literal>, <literal>undefined</literal> – special types.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Annotations are not supported in the types DSL.</simpara>
-</section>
-</section>
-<section xml:id="sec:Type_System_Implementation" role="language-n4js">
-<title>Type System Implementation</title>
-<simpara>The bulk of the type system’s functionality is implemented in packages <literal>org.eclipse.n4js.typesystem[.constraints|.utils]</literal>.
-Client code, e.g. in validations, should only access the type system through the facade class <literal>N4JSTypeSystem</literal>.
-Each of the main type system functions, called "judgments", are implemented in one of the concrete subclasses of
-base class <literal>AbstractJudgment</literal>. Internally, the type system is using a constraint solver for various purposes;
-entry point for this functionality is class <literal>InferenceContext</literal>. All these classes are a good entry point into
-the code base, for investigating further details.</simpara>
-<simpara>Some type information is cached (e.g., the type of an expression in the AST) and the above facade will take care
-to read from the cache instead of re-computing the information every time, as far as possible. This type cache is
-being filled in a dedicated phase during loading and processing of an N4JS resource;
-see <xref linkend="sec:Type_Inference_combined_with_AST_Traversal"/> and <xref linkend="sec:N4JS_Resource_Load_States"/> for details.</simpara>
-</section>
-<section xml:id="sec:Type_Inference_combined_with_AST_Traversal" role="language-n4js">
-<title>Type Inference of AST</title>
-<simpara>Most judgments provided by the facade <literal>N4JSTypeSystem</literal> and implemented by subclasses of <literal>AbstractJudgment</literal> are used
-ad-hoc whenever client code requires the information they provide. This is applied, in particular, to judgments</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>subtype</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>substTypeVariables</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>upperBound</literal> / <literal>lowerBound</literal></simpara>
-</listitem>
-</itemizedlist>
-<simpara>For judgment <literal>type</literal> footnote:<literal role="Currently only for [language-n4js">type</literal>, not for <literal role="language-n4js">expectedType</literal>,
-but this may be changed in a future, further refactoring.], however, the processing is very different: we make
-sure that the entire AST, i.e. all typable nodes of the AST, will be typed up-front in a single step, which
-takes place during the <emphasis>post-processing step</emphasis> of an N4JSResource (see <xref linkend="sec:N4JS_Resource_Load_States"/>), which
-also has a couple other responsibilities. By triggering post-processing when client code invokes the type judgment
-for the first time for some random AST node (at the latest; usually it is triggered earlier), we make sure that
-this sequence is always followed.</simpara>
-<simpara>The remainder of this section will explain this single-step typing of the entire AST in detail.</simpara>
-<section xml:id="sec:Type_Inference_combined_with_AST_Traversal__Background">
-<title>Background</title>
-<simpara>Originally, the N4JS type system could be called with any <literal>EObject</literal> at any given time, without any knowledge of the
-context. While this looked flexible in the beginning, it caused severe problems solving some inference cases, e.g.,
-the rule environment had to be prepared from the outside and recursion problems could occur, and it was also
-inefficient because some things had to be recalculated over and over again (although caching helped).</simpara>
-<simpara>It is better to do type inferencing (that is, computing the type of expressions in general) in a controlled manner.
-That is, instead of randomly computing the type of an expression in the AST, it is better to traverse the AST in a
-well-defined traversal order. That way, it is guaranteed that certain other nodes have been visited and, if not,
-either some special handling can kick in or an error can be reported. This could even work with XSemantics and the
-declarative style of the rules. The difference is that by traversing the AST in a controlled manner, the rules can
-make certain assumptions about the content of the rule-environment, such as that it always contains information
-about type variable bindings and that it always contains information about expected types etc.</simpara>
-<simpara>In that scenario, all AST nodes are visited and all types (and expected types) are calculated up-front. Validation
-and other parts then do not need to actually compute types (by calling the actual, Xsemantics-generated type system);
-instead, at that time all types have already been calculated and can simply be retrieved from the cache (this is
-taken care of by the type system facade <literal>N4JSTypeSystem</literal>).</simpara>
-<simpara>This also affects scoping, since all cross-references have to be resolved in this type computation step. However,
-even for scoping this has positive effects: E.g., the receiver type in property access expressions is always visited
-<emphasis>before</emphasis> visiting the selector. Thus it is not necessary to re-calculate the receiver type in order to perform scoping
-for the selector.</simpara>
-<simpara>The above refactoring was done in summer 2015. After this refactoring, we are still using Xsemantics to compute the
-types, i.e. the <literal>type</literal> judgement in Xsemantics was largely kept as before. However, the type judgment is invoked
-in a controlled traversal order for each typable AST node in largely one step (controlled by <literal>ASTProcessor</literal> and <literal>TypeProcessor</literal>).</simpara>
-<simpara>The upshot of this one-step type inference is that once it is completed, the type for every typable AST node is known.
-Instead of storing this information in a separate model, this information will be stored and persisted in the type model
-directly, as well as in transient fields of the AST <footnote><simpara>This is not yet implemented as of September 2015; types are still stored in a separate cache, the <literal>ASTMetaInfoCache</literal>.</simpara></footnote>. Currently, this applies only to types, not expected types;
-the inference of expected types could / should be integrated into the one-step inference as part of a future, further
-refactoring.</simpara>
-<table xml:id="tab:typeInferenceBeforeAfter" frame="all" rowsep="1" colsep="1">
-<title>Comparison of inference of type of AST nodes before / after refactoring.</title>
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="50*"/>
-<colspec colname="col_2" colwidth="50*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Before</entry>
-<entry align="left" valign="top">After</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara>ad-hoc type inference (when client code needs the type information)</simpara></entry>
-<entry align="left" valign="top"><simpara>up-front type inference (once for entire AST;
-later only reading from cache)</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>started anywhere</simpara></entry>
-<entry align="left" valign="top"><simpara>starts with root, i.e. the <literal>Script</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>Xsemantics rules traverse the AST at will, uncontrolled</simpara></entry>
-<entry align="left" valign="top"><simpara>well-defined, controlled traversal order</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>lazy, on-demand resolution of <literal>ComputedTypeRef</literal>s (they contain the resolution logic)</simpara></entry>
-<entry align="left" valign="top"><simpara>pro-active resolution of
-<literal>DeferredTypeRef</literal>s (they themselves are dumb)</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-</section>
-<section xml:id="sec:Triggering_Type_Inference_of_AST">
-<title>Triggering</title>
-<simpara>The up-front type inference of the entire AST is part of the post-processing of every N4JSResource and is thus
-triggered when post-processing is triggered. This happens when</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>someone directly calls <literal>#performPostProcessing()</literal> on an N4JSResource</simpara>
-</listitem>
-<listitem>
-<simpara>someone directly calls <literal>#resolveAllLazyCrossReferences()</literal> on an N4JSResource,</simpara>
-</listitem>
-<listitem>
-<simpara>EMF automatically resolves the first proxy, i.e. someone calls an EMF-generated getter for a value that is a proxy,</simpara>
-</listitem>
-<listitem>
-<simpara>someone asks for a type for the first time, i.e. calls <literal>N4JSTypeSystem#type()</literal>,</simpara>
-</listitem>
-<listitem>
-<simpara>…​</simpara>
-</listitem>
-</orderedlist>
-<simpara>Usually this happens after the types builder was run with <literal>preLinking==false</literal> and before validation takes place.
-For details, see classes <literal>PostProcessingAwareResource</literal> and <literal>N4JSPostProcessor</literal>.</simpara>
-</section>
-<section xml:id="sec:Traversal_Order_During_Type_Inference_of_AST">
-<title>Traversal Order</title>
-<simpara>The traversal order during post-processing is a bit tricky, as some things need to be done in a top-down order (only
-few cases, for now <footnote><simpara>In the future, the top-down order could become more important if inference of <emphasis>expected</emphasis> types is also integrated into post-processing.</simpara></footnote>), others in a bottom-up order (e.g. the main typing of AST nodes),
-and there is a third case in which several AST nodes are processed together (constraint-based type inference).</simpara>
-<simpara>Figure <xref linkend="fig:traversalOrder"/> provides an example of an AST and shows in which order the nodes are processed. Green
-numbers represent top-down processing, red numbers represent bottom-up processing and blue numbers represent the
-processing of the surrounding yellow nodes in a single step.</simpara>
-<figure xml:id="fig:traversalOrder">
-<title>Order in which AST nodes are being processed during post-processing.</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/06_typesystem/images/traversalOrder.png"/>
-</imageobject>
-<textobject><phrase>traversalOrder</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>In the code, this is controlled by class <literal>ASTProcessor</literal>. The two main processing methods are</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>#processNode_preChildren()</literal>, which will be invoked for all AST nodes in a top-down order (so top-down processing should be put here),</simpara>
-</listitem>
-<listitem>
-<simpara><literal>#processNode_postChildren()</literal>, which will be invoked for all AST nodes in a bottom-up order (so bottom-up processing should be put here).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The common processing of groups of adjacent yellow nodes (represented in the figure by the two yellow/brown
-triangles) is achieved by <literal>PolyProcessor</literal> telling the <literal>TypeProcessor</literal> to</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>ignore certain nodes (all yellow nodes) and</simpara>
-</listitem>
-<listitem>
-<simpara>invoke method <literal>PolyProcessor#inferType()</literal> for the root yellow node in each group (only the root!).
-.
-For details, see the two methods <literal>#isResponsibleFor()</literal> and <literal>#isEntryPoint()</literal> in <literal>PolyProcessor</literal>.</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Cross_References_During_Type_Inference_of_AST">
-<title>Cross-References</title>
-<simpara>While typing the entire AST, cross-references need special care. Three cases of cross-references need to be distinguished:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>backward reference</simpara>
-</entry>
-<entry>
-<simpara>= cross-reference within the same file to an AST node that was already processed</simpara>
-<itemizedlist>
-<listitem>
-<simpara>always legal</simpara>
-</listitem>
-<listitem>
-<simpara>processing: simply read the type from the cache that is currently being filled</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>forward reference</simpara>
-</entry>
-<entry>
-<simpara>= cross-reference within the same file to an AST node that was not yet processed</simpara>
-<itemizedlist>
-<listitem>
-<simpara>usually illegal<?asciidoc-br?>
-exception: legal if reference points to an <emphasis>identifiable subtree</emphasis> (a subtree of an AST with an identifiable element at its root)</simpara>
-</listitem>
-<listitem>
-<simpara>processing: forward process the identifiable subtree and report back the type of its root</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>references to other files</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>always legal, because they can, by nature, only point to an identifiable subtree in the other file’s AST</simpara>
-</listitem>
-<listitem>
-<simpara>processing: either …​</simpara>
-<itemizedlist>
-<listitem>
-<simpara>read type from TModule obtained from index (if available), or</simpara>
-</listitem>
-<listitem>
-<simpara>load other file from source, trigger its post-processing (if not in progress or completed already), forward process the identifiable subtree (if not processed already) and report back the type of its root.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Note that for references to an ancestor (upward references) or successor (downward references) within an AST, the
-classification as a forward or backward reference depends on whether we are in top-down or bottom-up processing.
-Figure <link linkend="fig:upwardDownward">Upward Downward</link> illustrates this: the left and right side show the same AST but on the
-left side we assume a top down processing whereas on the right we assume a bottom up processing. On both sides,
-backward references are shown in green ink (because they are unproblematic and always legal) and forward references
-are shown in red ink. Now, looking at the two arrows pointing from a node to its parent, we see that it is classified
-as a backward reference on the left side (i.e. top down case) but as a forward reference on the right side (i.e. bottom
-down case). Conversely, an arrow from a node to its child is classified as a forward reference on the left side and as
-a backward reference on the right side. Arrows across subtrees, however, are classified in the same way on the left and
-right side (see the horizontal arrows at the bottom).</simpara>
-<figure xml:id="fig:upwardDownward">
-<title>Backward and forward references in top-down and bottom-up processing.</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/06_typesystem/images/upwardDownward.png"/>
-</imageobject>
-<textobject><phrase>upwardDownward</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:Function_Accessor_Bodies_During_Type_Inference_of_AST">
-<title>Function/Accessor Bodies</title>
-<simpara>An important exception to the basic traversal order shown in Figure <xref linkend="fig:traversalOrder"/> is that the body of all
-functions (including methods) and field accessors is postponed until the end of processing. This is used to avoid
-unnecessary cycles during type inference due to a function’s body making use of the function itself or some other
-declarations on the same level as the containing function. For example, the following code relies on this:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let x = f();
-function f(): X {
- if(x) {
- // XPECT noerrors --> "any is not a subtype of X." at "x"
- return x;
- }
- return new X();
-}</programlisting>
-<simpara>Similar situation using fields and methods:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- d = new D();
- mc() {
- // XPECT noerrors --> "any is not a subtype of D." at "this.d"
- let tmp: D = this.d;
- }
-}
-class D {
- md() {
- new C().mc();
- }
-}</programlisting>
-<simpara>For details of this special handling of function bodies, see method <literal>ASTProcessor#isPostponedNode(EObject)</literal> and field
-<literal>ASTMetaInfoCache#postponedSubTrees</literal> and the code using it. For further investigation, change <literal>isPostponedNode()</literal> to always
-return false and debug with the two examples above (which will then show the incorrect errors mentioned in the XPECT
-comments) or run tests to find more cases that require this handling.</simpara>
-</section>
-<section xml:id="sec:Poly_Expressions_During_Type_Inference_of_AST">
-<title>Poly Expressions</title>
-<simpara>Polymorphic expressions, or <emphasis>poly expressions</emphasis> for short, are expressions for which the actual type depends on the
-expected type and/or the expected type depends on the actual type. They require constraint-based type inference
-because the dependency between the actual and expected type can introduce dependency cycles between the types of
-several AST nodes which are best broken up by using a constraint-based approach. This is particularly true when
-several poly expressions are nested. Therefore, poly expressions are inferred neither in top-down nor in bottom-up
-order, but all together by solving a single constraint system.</simpara>
-<simpara>Only a few types of expressions can be polymorphic; they are called <emphasis>poly candidates</emphasis>: array literals, object literals,
-call expressions, and function expressions. The following rules tell whether a poly candidate is actually poly:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>ArrayLiteral</literal> — always poly (because their type cannot be declared explicitly).</simpara>
-</listitem>
-<listitem>
-<simpara><literal>ObjectLiteral</literal> — if one or more properties do not have a declared type.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>CallExpression</literal> — if generic & not parameterized.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>FunctionExpression</literal> — if return type or type of one or more formal parameters is undeclared.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>This is a simplified overview of these rules, for details see method <literal>#isPoly(Expression)</literal> in <literal>AbstractPolyProcessor</literal>.</simpara>
-<simpara>The main logic for inferring the type of poly expressions is found in method <literal>#inferType()</literal> in class <literal>PolyProcessor</literal>.
-It is important to note that this method will only be called for root poly expressions (see above). In short, the basic
-approach is to create a new, empty <literal>InferenceContext</literal>, i.e. constraint system, add inference variables and constraints for
-the root poly expression and all its nested poly expressions, solve the constraint system and use the types in the solution
-as the types of the root and nested poly expressions. For more details see method <literal>#inferType()</literal> in class <literal>PolyProcessor</literal>.</simpara>
-<simpara>So, this means that nested poly expressions do not introduce a new constraint system but instead simply extend their parent
-poly’s constraint system by adding additional inference variables and constraints. <emphasis role="strong">But not every nested expression that is
-poly is a nested poly expression in that sense!</emphasis> Sometimes, a new constraint system has to be introduced. For example:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>child poly expressions that appear as argument to a call expression are nested poly expressions (i.e. inferred in same constraint system as the parent call expression),</simpara>
-</listitem>
-<listitem>
-<simpara>child poly expressions that appear as target of a call expression are <emphasis role="strong">not</emphasis> nested poly expressions and a new constraint system has to be introduced for them.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For details see method <literal>#isRootPoly()</literal> in <literal>AbstractPolyProcessor</literal> and its clients.</simpara>
-</section>
-<section xml:id="sec:Constraint_Solver_used_During_Type_Inference_of_AST">
-<title>Constraint Solver</title>
-<simpara>The simple constraint solver used by the N4JS type system, mainly for the inference of poly expressions, is implemented
-by class <literal>InferenceContext</literal> and the other classes in package <literal>org.eclipse.n4js.typesystem.constraints</literal>.</simpara>
-<simpara>The constraint solving algorithm used here is largely modeled after the one defined in <literal>The Java Language Specification 8</literal>,
-Chapter 18, but was adjusted in a number of ways, esp. by removing functionality not required for N4JS (e.g. primitive types,
-method overloading) and adding support for specific N4JS language features (e.g. union types, structural typing).</simpara>
-<simpara>For details see the API documentation of class <literal>InferenceContext</literal>.</simpara>
-</section>
-<section xml:id="sec:Type_Guards_During_Type_Inference_of_AST">
-<title>Type Guards</title>
-<simpara>During AST post-processing, the control and data flow analyses are performed.
-This means, that first a flow graph is created and then traversed.
-During the traversal, a type guard analysis is performed which saves information by evaluating <literal>instanceof</literal> expressions.
-As a result, the analysis provides a reliable set of RHS expressions of <literal>instanceof</literal> expressions for each AST element of type <literal>IdentifierRef</literal>.</simpara>
-<simpara>This set is evaluated in the <literal>TypeJudgments.java</literal> when typing <literal>IdentifierRef</literal> elements.
-In case the set is not empty, the types of all elements is calculated.
-The type of the <literal>IdentifierRef</literal> will then become the intersection of its original type and all types previously calculated.</simpara>
-</section>
-</section>
-<section xml:id="sec:Structural_Typing">
-<title>Structural Typing</title>
-<simpara>Structural typing as an optional subtyping mode in N4JS is implemented in <literal>StructuralTypingComputer</literal>, activated depending on
-the value of property <literal>typingStrategy</literal> in <literal>ParameterizedTypeRef</literal> and its subclasses.</simpara>
-</section>
-</chapter>
-<chapter xml:id="_type-index">
-<title>Type Index</title>
-<section xml:id="sec:Type_Index_Design_Rationale" role="language-n4js">
-<title>Design Rationale</title>
-<simpara>We use a separate types model to represent types, see <xref linkend="sec:Type_Model_and_Grammar"/>. Declared elements (e.g., classes)
-in N4JS are parsed and a new types model instance is derived from them. All type references (of the N4JS <link linkend="AC">AST</link>)
-are then bound to these type instances and not to the N4JS declaration. However, there exists a relation between a type
-and its declaration. The type instances (which are EObjects) are added to the resource of the N4JS file as part of
-the public interface of the resource. This public interface is represented by a <literal>TModule</literal>. While the actual source code
-is the first element of a resource (index 0), the module is stored at index 1. It contains the derived type information,
-the information about exported variables and functions as well as information about the project and vendor. The Xtext
-serializer ignores the additional element. Besides, the complete type instances are stored in the user data section of
-the <literal>IEObjectDescription</literal> of the <literal>TModule</literal>. Since the user data only allows strings to be stored, the EObjects are serialized
-(within a virtual resource). When a reference is then bound to a type, the type can be directly recreated (deserialized)
-from the user data. The deserialized EObject is then added to the appropriate resource. It is not necessary to load the
-complete file just to refer to a type from that file.</simpara>
-<simpara>The design relies on two key features of Xtext:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Besides the parsed text (i.e., the AST), other elements can be stored in a resource, which are then ignored by
-the Xtext serializer, while still being properly contained in an EMF resource.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal>DerivedStateAwareResource</literal> allows some kind of post processing steps when reading a resource. This enables a custom
-class, here <literal>N4JSDerivedStateComputer</literal>, to create the types models (TClass, TRole and so on) from the parsed <literal>N4ClassDeclaration</literal>,
-<literal>N4RoleDeclaration</literal> and so on.</simpara>
-</listitem>
-</orderedlist>
-<section xml:id="sec:Getting_the_Xtext_Index_Content_IResourceDescriptions">
-<title>Getting the Xtext Index (<literal>IResourceDescriptions</literal>) Content</title>
-<simpara>An instance of the <literal>IResourceDescriptions</literal> can be acquired from the resource description provider. Just like all services
-in Xtext, this can be injected into the client code as well. The resource descriptions accepts a non-null resource set.
-The resource set argument is mandatory to provide the index with the proper state. We are differentiating between three
-different state. The first one is the persisted one, basically the builder state is a resource description as well, and
-it provides a content that is based on the persisted state of the files (in our case the modules and package.json file)
-on the file system. The second one is the live scoped index, this is modification and dirty state aware. Namely when using
-this resource descriptions then an object description will be searched in the resource set itself first, then in the dirty
-editor’s index, finally among the persisted ones. The third index is the named builder scoped one. This index should not be
-used by common client code, since it is designed and implemented for the Xtex builder itself.</simpara>
-<simpara>A resource set and hence the index can be acquired from the N4JS core, in such cases an optional N4JS project can be specified.
-The N4JS project argument is used to retrieve the underlying Eclipse resource project (if present) and get the resource set from
-the resource set provider. This is completely ignored when the application is running in headless mode and Eclipse resource
-projects are not available. It is also important to note that the resource set is always configured to load only the persisted
-states.</simpara>
-<simpara>When the Eclipse platform is running, the workspace is available and the all N4JS projects are backed by an Eclipse resource
-project. With the Eclipse resource project the resource sets can be initialized properly via the resource set initializer
-implementations. This mechanism is used to get the global objects (such as console) and the built-in types (such as string,
-number) into the resource set via the corresponding resource set adapters. In the headless case a special resource set
-implementation is used; <literal>ResourceSetWithBuiltInScheme</literal>. This implementation is responsible to initialize the globals and the
-built-in types into itself.</simpara>
-</section>
-</section>
-<section xml:id="sec:Design_Overview" role="language-n4js">
-<title>Design Overview</title>
-<simpara><link linkend="fig:cd_TypeModelWithXtextIndex">Type Model With Xtext Index</link> shows a simplified UML class diagram with the involved
-classes. In the figure, a class (defined as N4ClassExpression in the <link linkend="AC">AST</link> and its type TClass) is used as a sample,
-declared type—roles or enums are handled similarly.</simpara>
-<simpara>In the Eclipse project build the <literal>N4JSResourceDescriptionManager</literal> (resp. by the logic of its super class) is called by the
-<literal>N4JSGenerateImmediatelyBuilderState</literal> to get the resource description for a resource. The resource description manager loads
-the resource to create / update the resource descriptions. Loading an Xtext resource means that it is reparsed again.
-All cross references are handled here only by the lazy linker so that the node model will contain an unresolved proxy
-for all cross references.</simpara>
-<simpara>After the resource is loaded there is a derived state installed to the resource. For this the <literal>N4JSDerivedStateComputer</literal> will
-be called. It will take the parse result (= EObject tree in first slot of the resource) and navigate through these objects
-to create type trees for each encountered exportable object that are stored in exported <literal>TModule</literal> of the resource.
-<link linkend="fig:cd_CreateTypeFromAST">Create Type From AST</link>, a snippet of <link linkend="fig:cd_TypeModelWithXtextIndex">Type Model with Xtext Index</link>,
-shows only the classes involved when creating the types from the resource.</simpara>
-<figure xml:id="fig:cd_CreateTypeFromAST" role="center">
-<title>Type From AST</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/cd_CreateTypeFromAST.png"/>
-</imageobject>
-<textobject><phrase>cd CreateTypeFromAST</phrase></textobject>
-</mediaobject>
-</figure>
-<figure xml:id="fig:cd_TypeModelWithXtextIndex" role="center">
-<title>Create Type From Index</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/cd_CreateTypeFromIndex.png"/>
-</imageobject>
-<textobject><phrase>cd CreateTypeFromIndex</phrase></textobject>
-</mediaobject>
-</figure>
-<figure xml:id="fig:cd_SerializeToIndex" role="center">
-<title>Serialize To Index</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/cd_SerializeToIndex.png"/>
-</imageobject>
-<textobject><phrase>cd SerializeToIndex</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara role="language-javascript">For these elements types have to be derived as they are exportable: <literal>N4ClassDeclaration</literal>, <literal>N4RoleDeclaration</literal>, <literal>N4InterfaceDeclaration</literal>,
-<literal>N4EnumDeclaration</literal>, <literal>ExportedVariableDeclaration</literal> and <literal>FunctionDeclaration</literal>.</simpara>
-<simpara>After loading and initializing the resources now all cross references in the resources are resolved. For this the
-<literal>ErrorAwareLinkingService</literal> is used. This class will in turn call the <literal>N4JSScopeProvider</literal> to first try to do scoping locally
-but eventually also delegate to the global scope provider to find linked elements outside the current resource. This
-will be done e.g. for every import statement inside the N4JS resource.</simpara>
-<simpara>For determine the global scope all visible containers for this resource are calculated. For this the project description
-(= loaded package.json file) is used to determine which folders of the current project should be included for looking for
-N4JS resources. Also all referenced projects and their resources are added to the visible containers. For these containers
-<literal>N4JSGlobalScopeProvider</literal> builds up a container scope. This container scope will be a <literal>N4JSTypesScope</literal> instance.</simpara>
-<simpara>For the actual linked element in the resource to be resolved, its fully qualified name is used. This name is calculated by
-using the <literal>IQualifiedNameConverter</literal>. We bound a custom class named <literal>N4JSQualifiedNameConverter</literal> who converts the <literal>/</literal> inside the
-qualified name to a dot, so e.g. <literal>my/module/MyFileName</literal> is converted to <literal>my.module.MyFileName</literal>. Btw. the initial qualified name
-was derived from the node model.</simpara>
-<simpara>With this qualified name <literal>N4JSTypeScope.getSingleElement</literal> is called. This method does the actual resolving of the cross reference.
-For this the URI of the cross reference is used to determine the linked resource.</simpara>
-<simpara>There are now three cases:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If the resource which contains the linked EObject is already loaded the EObject description found for the URI is returned</simpara>
-</listitem>
-<listitem>
-<simpara>If the resource is not loaded but the first slot of the resource is empty the referenced type is tried to be rebuild from
-an existing resource description for the linked resource inside the Xtext index.</simpara>
-</listitem>
-<listitem>
-<simpara>If the resource is not loaded and the first slot is set, the linked EObject will be resolved with the fragment of the
-given URI.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>While calculating the resource description for a <literal>N4JSResource</literal>, the EObject descriptions of their exported objects have to be
-calculated as well. For this the <literal>N4JSResourceDescriptionStrategy</literal> is used. For computing the exported objects of a resource only
-the root <literal>TModule</literal> and its contained types and variables are taken in consideration.</simpara>
-<simpara>The EObjectDescriptions for a n4js resource include:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>An exported representation of the derived <literal>TModule</literal>. This carries these properties:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a qualified name (e.g. <literal>my.module.MyFileName</literal> when the resource is stored under <literal>src/my/module/MyFileName.js</literal> in the project and
-the project description has marked src has src folder). The calculation of the qualified name is delegated to the <literal>N4JSNamingUtil</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>the user data which is the serialized string of the exported <literal>TModule</literal> itself. It includes the types determined for this
-resource, so for every element found in this resource, that is contained in an <literal>ExportStatement</literal>, an EObject has been created
-before in <literal>N4JSDerivedStateComputer</literal>. In most cases this an EObject extending <literal>Type</literal> from the types model, e.g. <literal>TClass</literal> for
-<literal>N4ClassDeclaration</literal>. There is an exception for <literal>ExportedVariableDeclaration</literal> where <literal>TVariable</literal> is used as representative (and this
-EObject is not contained in the types model only in the N4JS model). For usability reasons (quicker quick fix etc.), also
-top level types not exported yet are stored in the <literal>TModel</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>the information on project and vendor id are part of the module descriptor.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Descriptions for all top level types that are defined in the resource. These descriptions do not have any special properties,
-so they just have a name.</simpara>
-</listitem>
-<listitem>
-<simpara>All exported variables are also described in the resource description. They don’t carry any special information either.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The EObjectDescription for an EObject contained in an <literal>ExportStatement</literal>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the qualified name of the module export (e.g. for a <literal>N4ClassDeclaration</literal> the qualified name <literal>my.module.MyFileName.MyClassName</literal> would
-be produced, when the resource is stored under <literal>src/my/module/MyFileName.js</literal> in the project, the project description has marked
-src has src folder and the N4 class uses the name MyClassName]). The calculation of the qualified name is delegated to the
-<literal>N4JSNamingUtil</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>the EObject represented by the EObject description, here this is not the actual EObject from N4JS but the type EObject from
-the TypeSystem, that has been inferenced by using <literal>N4JSTypeInferencer</literal></simpara>
-</listitem>
-<listitem>
-<simpara>the user data is only an empty map for this EObjectDescription</simpara>
-</listitem>
-</itemizedlist>
-<simpara>With this the resource description for a resource should be fully created / updated. <link linkend="fig:cd_SerializeToIndex">Serialize to Index</link>
-shows the classes involved creating the resource and EObjectDescriptions, along with the serialized type information.</simpara>
-</section>
-<section xml:id="sec:N4JS_Resource_Load_States">
-<title>N4JS Resource Load States</title>
-<simpara>Below state diagram depicts the state transitions when loading and resolving an N4JS resource.</simpara>
-<figure role="center">
-<title>N4JS Resource resolution states</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/resource_set_load_states.png"/>
-</imageobject>
-<textobject><phrase>resource set load states</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Additionally, the following table relates the values of the resource’s flags to the states.</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="9">
-<colspec colname="col_1" colwidth="11.1111*"/>
-<colspec colname="col_2" colwidth="11.1111*"/>
-<colspec colname="col_3" colwidth="11.1111*"/>
-<colspec colname="col_4" colwidth="11.1111*"/>
-<colspec colname="col_5" colwidth="11.1111*"/>
-<colspec colname="col_6" colwidth="11.1111*"/>
-<colspec colname="col_7" colwidth="11.1111*"/>
-<colspec colname="col_8" colwidth="11.1111*"/>
-<colspec colname="col_9" colwidth="11.1112*"/>
-<thead>
-<row>
-<entry align="left" valign="top">State</entry>
-<entry align="left" valign="top">Parse Result</entry>
-<entry align="left" valign="top">AST</entry>
-<entry align="left" valign="top">TModule</entry>
-<entry align="left" valign="top">ASTMetaInfoCache</entry>
-<entry align="left" valign="top">loaded</entry>
-<entry align="left" valign="top">fullyInitialized</entry>
-<entry align="left" valign="top">fullyProcessed</entry>
-<entry align="left" valign="top">reconciled</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Created</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Created'</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Loaded</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>with lazy linking proxies</simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Pre-linked</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>with lazy linking proxies</simpara></entry>
-<entry align="left" valign="top"><simpara>with stubs</simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Fully Initialized</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>with lazy linking proxies</simpara></entry>
-<entry align="left" valign="top"><simpara>with DeferredTypeRefs</simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Fully Processed</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Loaded from Description</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>proxy</simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>indeterminate</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Loaded from Description'</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>proxy</simpara></entry>
-<entry align="left" valign="top"><simpara>with DeferredTypeRefs</simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>indeterminate</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Fully Initialized ®</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>with lazy linking proxies</simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara><literal>null</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>indeterminate</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>false</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Fully Processed ®</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>available</simpara></entry>
-<entry align="left" valign="top"><simpara>indeterminate</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-<entry align="left" valign="top"><simpara>true</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Remarks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>oddities are shown in red ink, in the above figure.</simpara>
-</listitem>
-<listitem>
-<simpara>in the above figure:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>"AST (proxy)" means the AST consists of only a single node of type <literal>Script</literal> and that is a proxy,</simpara>
-</listitem>
-<listitem>
-<simpara>"AST (lazy)" means the AST is completely created, but cross-references are represented by unresolved
-Xtext lazy-linking proxies,</simpara>
-</listitem>
-<listitem>
-<simpara>"TModule (stubs)" means the TModule has been created with incomplete information, e.g. return types of
-all TMethods/TFunctions will be <literal>null</literal> (only used internally by the incremental builder),</simpara>
-</listitem>
-<listitem>
-<simpara>"TModule (some deferred)" means the TModule has been created, does not contain stub, but some
-`TypeRef`s are `DeferredTypeRef`s that are supposed to be replaced by proper `TypeRef`s during post-processing.</simpara>
-</listitem>
-<listitem>
-<simpara>"AST" and "TModule" means the AST/TModule is available without any qualifications.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>state <emphasis role="strong">Created'</emphasis>: only required because Xtext does not clear flag <literal>fullyInitialized</literal> upon unload; that is done lazily
-when <literal>#load()</literal> is invoked at a later time.. Thus, we do not reach state <emphasis role="strong">Created</emphasis> when unloading from state
-<emphasis role="strong">Fully Initialized</emphasis> but instead get to state <emphasis role="strong">Created'</emphasis>. To reach state <emphasis role="strong">Created</emphasis> from <emphasis role="strong">Fully Initialized</emphasis> we have to
-explicitly invoke <literal>#discardDerivedState()</literal> before(!) unloading.</simpara>
-</listitem>
-<listitem>
-<simpara>state <emphasis role="strong">Loaded from Description'</emphasis>: transition <literal>#unloadAST()</literal> from state <emphasis role="strong">Fully Initialized</emphasis> leaks a non-post-processed
-TModule into state <emphasis role="strong">Loaded from Description</emphasis>, which is inconsistent with actually loading a TModule from the index,
-because those are always fully processed. Hence, the addition of state <emphasis role="strong">Loaded from Description'</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara>states <emphasis role="strong">Fully Initialized ®</emphasis> and <emphasis role="strong">Fully Processed ®</emphasis>: these states are reached via reconciliation of a pre-existing
-TModule with a newly loaded AST. These states differ in an unspecified way from their corresponding non-reconciled
-states. For example, in state <emphasis role="strong">Fully Initialized ®</emphasis> the TModule does not contain any DeferredTypeRefs while, at the
-same time, the TModule isn’t fully processed, because proxy resolution, typing, etc. have not taken place, yet.</simpara>
-</listitem>
-<listitem>
-<simpara>TODO old text (clarify this; I could not reproduce this behavior): when <literal>unloadAST</literal> is called, <literal>fullyInitialized</literal> remains
-unchanged. This is why the value of <literal>fullyInitialized</literal> should be indeterminate in row <emphasis role="strong">Loaded from Description</emphasis>; it
-depends on the previous value if the state <emphasis role="strong">Loaded from Description</emphasis> was reached by calling <literal>unloadAST</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Type_Builder" role="language-n4js">
-<title>Types Builder</title>
-<simpara>When a resource is loaded, it is parsed, linked, post-processed, validated and eventually compiled. For linking and validation
-type information is needed, and as described above the type information is created automatically when loading a resource using
-the types builder. <link linkend="fig:ad_resourceLoading">Resource Loading</link> shows an activity model with the different actions performed when
-a resource is loaded.</simpara>
-<figure xml:id="fig:ad_resourceLoading" role="center">
-<title>Activity Diagram, Resource Loading</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/ad_resourceLoading.png"/>
-</imageobject>
-<textobject><phrase>ad resourceLoading</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The blue colored steps are standard Xtext workflow. Handling the TModule and storing that in the index are N4 specific (red background).</simpara>
-<section xml:id="sec:Type_Inference_not_allowed_in_Type_Builder">
-<title>Type Inference not allowed in Types Builder</title>
-<simpara>A crucial point in the workflow described above is the combination of types model building and type inference. In some cases,
-the type of a given element is not directly stated in the AST but has to be inferred from an expression and other types. For
-example, when a variable declaration does not declare the variable’s type explicitly but provides an initializer expression,
-the actual type of the variable is inferred to be the type of the expression.</simpara>
-<simpara>However, the types builder cannot be allowed to use type inference, mainly for two reasons:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>type inference through Xsemantics could lead to resolution of cross-references (i.e. EMF proxies generated by the lazy
-linker) and because the types builder is triggered when getContents() is called on the containing <literal>N4JSResource</literal> this would
-break a basic contract of EMF resources.</simpara>
-</listitem>
-<listitem>
-<simpara>type inference could cause other resources to be loaded which would lead to problems (infinite loops or strange results)
-in case of circular dependencies. This is illustrated in <link linkend="fig:sd_typesBuilder_problem">Types Builder Problem</link> and
-<link linkend="fig:sd_typesBuilder_proxies">Types Builder Proxies</link>.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Therefore, whenever the type of a particular element has to be inferred, the types builder will use a special type reference
-called <literal>DeferredTypeRef</literal> <footnote><simpara>The <literal role="language-n4js">DeferredTypeRef</literal> has replaced the old <literal role="language-n4js">ComputedTypeRef</literal> that had been used until Summer 2015; those were resolved lazily when the type was actually needed (triggered on demand). For a discussion of this change see <xref linkend="sec:Type_Inference_combined_with_AST_Traversal__Background"/> and in particular <xref linkend="tab:typeInferenceBeforeAfter"/>.</simpara></footnote>,
-in order to defer the actual type inference to a later stage, i.e. the post-processing stage.</simpara>
-<figure xml:id="fig:sd_typesBuilder_problem" role="center">
-<title>Sequence Diagram, Types Builder Problem</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/sd_typesBuilder_problem.png"/>
-</imageobject>
-<textobject><phrase>sd typesBuilder problem</phrase></textobject>
-</mediaobject>
-</figure>
-<figure xml:id="fig:sd_typesBuilder_proxies" role="center">
-<title>Sequence Diagram, Types Builder with Proxies</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/sd_typesBuilder_proxies.png"/>
-</imageobject>
-<textobject><phrase>sd typesBuilder proxies</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:ComputedTypeReferences">
-<title>Deferred Type References</title>
-<simpara>Whenever type inference would be required to obtain the actual type of an element, the types builder will insert a stub to defer
-actual type inference (see previous section). A dedicated subclass of <literal>TypeRef</literal>, called <literal>DeferredTypeRef</literal>, is used that contains neither
-the actual type information nor any information necessary to perform the type inference at a later point in time. Later, this
-<literal>DeferredTypeRef</literal> will be replaced during post-processing, see <literal>TypeDeferredProcessor</literal>.</simpara>
-<simpara>All <literal>DeferredTypeRef</literal>s will be replaced by the actual types during post-processing. One important reason for resolving
-all <literal>DeferredTypeRef</literal>s as early as possible is that they are not suited for serialization and therefore have to be removed
-from the types model before populating the Xtext index, which includes serializing the TModule into the user data of the
-root element. This is always assured by the logic that manages the triggering of the post-processing phase.</simpara>
-<simpara>To manually trigger resolution of all <literal>DeferredTypeRef</literal>s in a given types model, simply call method <literal>performPostProcessing(CancelIndicator)</literal>
-of the containing <literal>N4JSResource</literal> (should never be required by client code such as validations).</simpara>
-</section>
-<section xml:id="sec:Use_cases_of_ComputedTypeRef">
-<title>Use cases of DeferredTypeRef</title>
-<simpara>Currently, <literal>DeferredTypeRef</literal>s are created by the types builder only in these cases:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>actual type of an exported TVariable if no declared type but an initialization expression are given.</simpara>
-</listitem>
-<listitem>
-<simpara>actual type of a TField if no declared type but an initialization expression are given.</simpara>
-</listitem>
-<listitem>
-<simpara>actual type of properties of ObjectLiterals if not declared explicitly.</simpara>
-</listitem>
-<listitem>
-<simpara>actual type of formal parameters and return value of function expressions if not declared explicitly.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Note that this overview might easily get out-dated; see references to class <literal>DeferredTypeRef</literal> in the code.</simpara>
-</section>
-</section>
-<section xml:id="sec:Incremental_Builder_Overview" role="language-n4js">
-<title>Incremental Builder (Overview)</title>
-<simpara>This section provides a brief overview of how the incremental builder works.</simpara>
-<simpara>General remarks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The N4JS incremental builder is a combination of Eclipse builder infrastructure, Xtext-specific builder functionality and
-several adjustments for N4JS and N4MF.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal>IBuilderState</literal> implementation is identical to the persisted Xtext index. No matter how many Xtext languages are supported
-by the application, only a single <literal>IBuilderState</literal> instance is available in the application. Since we have one single <literal>IBuilderState</literal>,
-we have one single persisted Xtext index throughout the application.</simpara>
-</listitem>
-<listitem>
-<simpara>For simplicity, the below description assumes we have only N4JS projects in the workspace and no other Xtext languages are
-installed.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Major components:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>XtextBuilder</literal> (inherits from Eclipse’s <literal>IncrementalProjectBuilder</literal>):</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the actual incremental builder</simpara>
-</listitem>
-<listitem>
-<simpara>note: Eclipse will create one instance of <literal>XtextBuilder</literal> per project at startup.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><literal>IBuilderState</literal> (Xtext specific; no Eclipse pendant):<?asciidoc-br?>
-identical to the <literal>Xtext index</literal>, i.e. the globally shared, persisted instance of<?asciidoc-br?>
-<literal>IResourceDescriptions</literal>.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Main workflow:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>for each project that contains at least one resource that requires rebuilding, Eclipse will call the
-project’s <literal>XtextBuilder</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>each <literal>XtextBuilder</literal> will perform some preparations and will then delegate to <literal>IBuilderState</literal> which will iterate over
-all resources in the builder’s project that require rebuilding.</simpara>
-</listitem>
-</orderedlist>
-<section xml:id="sec:Incremental_Builder_Overview__XtextBuilder">
-<title>XtextBuilder</title>
-<simpara>Whenever a change in the workspace happens …​</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><anchor xml:id="itm:start" xreflabel="[itm:start]"/> Eclipse will collect all projects that contain changed resources and compute a project-level build
-order (using the <literal>build order</literal> of the workspace, see <literal>Workspace#getBuildOrder()</literal>, which is based on project dependencies)</simpara>
-</listitem>
-<listitem>
-<simpara>for the first <footnote><simpara>First, according to the build order.</simpara></footnote> project with changed resources, Eclipse will invoke
- method <literal>IncrementalProjectBuilder#build(int,Map,IProgressMonitor)</literal> of the project’s <literal>XtextBuilder</literal><?asciidoc-br?>
-(NOTE: from this point on, we are in the context of a <literal>current project</literal>)</simpara>
-</listitem>
-<listitem>
-<simpara>in <literal>XtextBuilder#build(int,Map,IProgressMonitor)</literal>:<?asciidoc-br?>
-the builder creates an empty instance of <literal>ToBeBuilt</literal> (Xtext specific)</simpara>
-</listitem>
-<listitem>
-<simpara>in <literal>XtextBuilder#incrementalBuild(IResourceDelta,IProgressMonitor)</literal>:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>The builder will iterate over all files in the project and for each will notify a <literal>ToBeBuiltComputer</literal> about the
-change (added, updated, or deleted) which can then decide how to update the <literal>ToBeBuilt</literal> instance,</simpara>
-</listitem>
-<listitem>
-<simpara>then forwards to <literal>#doBuild()</literal> .</simpara>
-<simpara>Note: if user changes 1..* files in a single project but later more files in other, dependant projects
- need to be built, the above step will happen for all projects, but will have an effect only for the first project that contains the actual file changes (i.e. in the standard case of saving a single file <literal>ToBeBuilt</literal> will always be non-empty for the <literal>first</literal> project, and always empty for the other, dependant projects; if a <literal>Save All</literal> is done, <literal>ToBeBuilt</literal> could be non-empty for later projects as well).</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>in <literal>XtextBuilder#doBuild(ToBeBuilt,IProgressMonitor,BuildType)</literal>:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>first check if <literal>ToBeBuilt</literal> is empty AND global build queue does not contain URIs for current project → then abort (nothing to do here)</simpara>
-</listitem>
-<listitem>
-<simpara>creates instance of BuildData with:</simpara>
-<orderedlist numeration="lowerroman">
-<listitem>
-<simpara>name of current project (as string)</simpara>
-</listitem>
-<listitem>
-<simpara>newly created, fresh <literal>ResourceSet</literal></simpara>
-</listitem>
-<listitem>
-<simpara>the <literal>ToBeBuilt</literal> (containing URIs of actually changed resources within current project, possibly filtered by <literal>ToBeBuiltComputer</literal>)</simpara>
-</listitem>
-<listitem>
-<simpara>the <literal>QueuedBuildData</literal> (an injected singleton)</simpara>
-</listitem>
-<listitem>
-<simpara>mode flag <literal>indexingOnly</literal> (only true during crash recovery)</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>invoke <literal>IBuilderState</literal> passing the <literal>BuildData</literal><?asciidoc-br?>
-→ updates itself (it is the global Xtext index) to reflect all changes in <literal>current project</literal>; validates and updates markers; runs transpiler (see below for details)</simpara>
-</listitem>
-<listitem>
-<simpara>invoke all registered <literal>IXtextBuilderParticipants</literal> (Xtext specific) for the <literal>current project</literal></simpara>
-<itemizedlist>
-<listitem>
-<simpara>this is where normally we would do validation and run the transpiler; however, for performance reasons (do not load resource again) we already do this in the <literal>IBuilderState</literal> (this is the idea of the <literal>GenerateImmediatelyBuilderState</literal>)</simpara>
-</listitem>
-<listitem>
-<simpara>in our implementation, almost nothing is done here, except trivial stuff such as deleting files during clean build</simpara>
-<simpara>At this point: returning from all methods.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>back in <literal>XtextBuilder#build(int,Map,IProgressMonitor)</literal>:<?asciidoc-br?>
-→ return with an array of IProjects; in our case: we return all other N4JSProjects referenced in the package.json of the project</simpara>
-<itemizedlist>
-<listitem>
-<simpara>important: these are <emphasis role="strong">not</emphasis> the projects that will be processed next: we need to continue with projects that depend on the current project, not with projects the current project depends on!</simpara>
-</listitem>
-<listitem>
-<simpara>Eclipse calls the returned projects <literal>interestingProjects</literal> and uses that as a hint for further processing; details not discussed here.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>continue with step <link linkend="itm:start">one</link>:<?asciidoc-br?>
-Eclipse will invoke <literal>XtextBuilder#build(int,Map,IProgressMonitor)</literal> again for all other projects that have a dependency to the <literal>current project</literal> of the previous iteration, plus all remaining projects with changed resources.</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Incremental_Builder_Overview__IBuilderState">
-<title>IBuilderState</title>
-<simpara>Invoked: once for each project containing a changed resource and dependant projects.<?asciidoc-br?>
-Input: one instance of <literal>BuildData</literal>, as created by <literal>XtextBuilder</literal>, containing:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>name of current project (as string)</simpara>
-</listitem>
-<listitem>
-<simpara>newly created, fresh <literal>ResourceSet</literal></simpara>
-</listitem>
-<listitem>
-<simpara>the <literal>ToBeBuilt</literal></simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>set of to-be-deleted URIs</simpara>
-</listitem>
-<listitem>
-<simpara>set of to-be-updated URIs</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>the <literal>QueuedBuildData</literal>, an injected singleton maintaining the following values <footnote><simpara>These are not really input values but rather values changed during the following invocation of the IBuilderState that need to be carried over from one invocation to the next.</simpara></footnote>:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>a queue of URIs per project (below called the <literal>global queue</literal>)<?asciidoc-br?>
-(actually stored in <literal>QueuedBuildData#projectNameToChangedResource</literal>)</simpara>
-</listitem>
-<listitem>
-<simpara>a collection of <literal>all remaining URIs</literal><?asciidoc-br?>
-(derived value: queued URIs of all projects + queues URIs not associated to a project (does not happen in N4JS))</simpara>
-</listitem>
-<listitem>
-<simpara>a collection of <literal>pending deltas</literal> (always empty in N4JS; probably only used for interaction with Java resources)</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>mode flag <literal>indexingOnly</literal> (only true during crash recovery)</simpara>
-</listitem>
-</orderedlist>
-<section xml:id="copy-and-update-xtext-index">
-<title>Copy and Update Xtext Index</title>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>in <literal>IBuilderState#update(BuildData,IProgressMonitor)</literal>:<?asciidoc-br?>
-creates a copy of its <literal>ResourceDescriptionsData</literal> called <literal>newData</literal> <footnote><simpara>Once the build phase has ended, this copied and modified Xtext index will replace the actual state of the builder state and will be persisted on graceful application shutdown.</simpara></footnote></simpara>
-</listitem>
-<listitem>
-<simpara>in <literal>AbstractBuilderState#doUpdate(…​)</literal>:<?asciidoc-br?>
-updates <literal>newData</literal> by writing new resource descriptions into it.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Creates a new load operation (<literal>LoadOperation</literal>) instance from the <literal>BuildData#getToBeUpdated()</literal> and loads all entries. While iterating and loading the resource descriptions, it updates <literal>newData</literal> by registering new resource descriptions that are being created on the fly from the most recent version of the corresponding resources.</simpara>
-</listitem>
-<listitem>
-<simpara>Adds these resources to the current project’s build queue. (<literal>BuildData#queueURI(URI uri)</literal>)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>for all to-be-deleted URIs given in <literal>ToBeBuilt</literal> in the <literal>BuildData</literal>, removes the corresponding <literal>IResourceDescription</literal> from <literal>newData</literal></simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>ToBeBuilt#getAndRemoveToBeDeleted()</literal> returns all URIs that have been marked for deletion but not marked for update and will clear the set of to-be-deleted URIs in <literal>ToBeBuilt</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="build-state-setup-phase">
-<title>Build State Setup Phase</title>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Calculates a set <literal>allRemainingURIs</literal> <footnote><simpara>This set of URIs will contain the URIs of all resources that are available in the copied Xtext index but not yet directly processed by the builder in the current build phase. These URIs will later be used as candidates for all resources that might be marked as affected ones and queued by the builder for forthcoming build phases.</simpara></footnote> as follows:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Initially contains all resource URIs from <literal>newData</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>All URIs will be removed from it that are marked for update (<literal>BuildData#getToBeUpdated()</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>Finally, all URIs will be removed from it that are already queued for build/rebuild. (<literal>BuildData#getAllRemainingURIs()</literal>).</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Creates an empty set <literal>allDeltas</literal> of resource description deltas<?asciidoc-br?>
-(c.f. <literal>IResourceDescription.Delta</literal>). <footnote><simpara>This set eventually represents all changes that were made during the current build phase. Note that <literal>allChanges</literal> might contain resource description deltas that do not represent an actual change, it is processed by the builder but the underlying information stored in the user data is still unchanged.</simpara></footnote></simpara>
-</listitem>
-<listitem>
-<simpara><anchor xml:id="itm:processDeleted" xreflabel="[itm:processDeleted]"/> <emphasis role="strong">Process Deleted:</emphasis> for all to-be-deleted URIs, creates a delta where the old state is the current state of the resource and the new state is <literal>null</literal> and adds it to <literal>allDeltas</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Adds all <literal>pending deltas</literal> from <literal>QueuedBuildData</literal> to <literal>allDeltas</literal> (does not apply to N4JS).</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong"><anchor xml:id="itm:enqueueAffectedResources" xreflabel="[itm:enqueueAffectedResources]"/>Enqueue affected resources, part 1:</emphasis> adds to the <literal>global queue</literal> the URIs of all resources affected by the changes in <literal>allDeltas</literal>.</simpara>
-<note>
-<simpara>For N4JS, <literal>allDeltas</literal> always seems to be empty at this point, so this does nothing at all.</simpara>
-</note>
-</listitem>
-<listitem>
-<simpara>Creates an empty set <literal>changedDeltas</literal> for storing deltas that were modified by the build phase and represent an actual change. Unlike <literal>allDeltas</literal>, this set contains only those URIs that were processed by the builder - the underlying user data information contains the differences between the old and the new state.</simpara>
-</listitem>
-<listitem>
-<simpara>Creates a new <literal>current queue</literal> and adds all URIs from the <literal>global queue</literal> that belong to the <literal>current project</literal>.</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="process-queued-uris">
-<title>Process Queued URIs</title>
-<simpara>Processes all elements from the queue until it contains no more elements.</simpara>
-<orderedlist xml:id="itm:loadRes" numeration="arabic">
-<listitem>
-<simpara>Load the resource for the first/next URI on the current queue</simpara>
-<note>
-<simpara>In case of a move, the loaded resource could have a different URI!</simpara>
-</note>
-</listitem>
-<listitem>
-<simpara>Once the resource has been loaded, it removes its URI from the current queue to ensure it will not be processed again.</simpara>
-</listitem>
-<listitem>
-<simpara>If the loaded resource is already marked for deletion, stop processing this resource and continue with next URI from the current queue (go to step <link linkend="itm:loadRes">Load Res</link>)
-<footnote><simpara>Note that deltas for to-be-deleted resources were already added to <literal>allDeltas</literal> upfront in step <link linkend="itm:processDeleted">Process Deleted</link>.</simpara></footnote></simpara>
-</listitem>
-<listitem>
-<simpara>Resolves all lazy cross references in the loaded resource. This will trigger post-processing, including all type inference (c.f. <literal>ASTProcessor#processAST(…​)</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>Creates a delta for the loaded resource, including</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>a resource description based on the new state of the resource, wrapped into the <literal>EObject</literal>-based resource description (as with the Xtext index persistence in <literal>EMFBasedPersister#saveToResource()</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>a resource description for the same resource with the state before the build process.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Adds this new delta to <literal>allDeltas</literal> and, if the delta represents a change (according to <literal>DefaultResourceDescriptionDelta#internalHasChanges()</literal>), also adds it to <literal>changedDeltas</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Adds the resource description representing the new state, stored in the delta, to <literal>newData</literal>, i.e. the copied <literal>ResourceDescriptionsData</literal>, replacing the old resource description of the loaded resource <footnote><simpara>This happens through a call to <literal role="language-n4js">CurrentDescriptions#register(Delta)</literal></simpara></footnote>.</simpara>
-</listitem>
-<listitem>
-<simpara>If the current queue is non-empty, go to step <link linkend="itm:loadRes">Load Res</link> and continue with the next URI in the current queue.</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="queueing-affected-resources">
-<title>Queueing Affected Resources</title>
-<simpara>When the current queue contains no more URIs (all have been processed) …​</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><anchor xml:id="itm:updateGlobalQueue" xreflabel="[itm:updateGlobalQueue]"/> <emphasis role="strong">Enqueue affected resources, part 2:</emphasis> add to the global queue URIs for all resources affected by the changes in <literal>changedDeltas</literal> <footnote><simpara>Unlike in step <link linkend="itm:enqueueAffectedResources">Enqueue Affected Resources</link>, we now use <literal>changedDeltas</literal> instead of <literal>allDeltas</literal> as a basis.</simpara></footnote>.</simpara>
-</listitem>
-<listitem>
-<simpara>Returns from <literal>#doUpdate()</literal>, returning <literal>allDeltas</literal> (only used for event notification).</simpara>
-</listitem>
-<listitem>
-<simpara>back in <literal>IBuilderState#update(BuildData,IProgressMonitor)</literal>:<?asciidoc-br?>
-makes the <literal>newData</literal> the publicly visible, persistent state of the IBuilderState (i.e. the <literal>official</literal> Xtext index all other code will see).</simpara>
-</listitem>
-</orderedlist>
-<simpara>We now provide some more details on how the global queue is being updated, i.e. steps <link linkend="itm:enqueueAffectedResources">Enqueue Affected Resources</link> and <link linkend="itm:updateGlobalQueue">Update Global Queue</link>.
-Due to the language specific customizations for N4JS, this second resource-enqueuing phase is the trickiest part of the incremental building process and has the largest impact on how other resources will be processed and enqueued at forthcoming builder state phases.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If <literal>allDeltas</literal> is empty, nothing to do.</simpara>
-</listitem>
-<listitem>
-<simpara>If <literal>allDeltas</literal> contains at least one element, we have to check other affected resources by going through the set of all resource URIs (<literal>allRemainingURIs</literal>) calculated in in the beginning of the build process.</simpara>
-</listitem>
-<listitem>
-<simpara>Assume we have at least one element in the <literal>allDeltas</literal> set, the latter case is true and we must check all elements whether they are affected or not. We simply iterate through the <literal>allRemainingURIs</literal> set and retrieve the old state of the resource description using the resource URI.</simpara>
-</listitem>
-<listitem>
-<simpara>Once the resource description with the old state is retrieved, we check if it is affected through the corresponding resource description manager. Since we currently support two languages, we have two different ways for checking whether a resource has changed or not. One for package.json files and the other for the N4JS language related resources.</simpara>
-</listitem>
-<listitem>
-<simpara>The package.json method is the following: get all project IDs referenced from the <literal>candidate</literal> package.json and compare it with the container-project name of the package.json files from the <literal>deltas</literal>. The referenced IDs are the followings:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>tested project IDs,</simpara>
-</listitem>
-<listitem>
-<simpara>implemented project IDs,</simpara>
-</listitem>
-<listitem>
-<simpara>dependency project IDs,</simpara>
-</listitem>
-<listitem>
-<simpara>provided runtime library IDs,</simpara>
-</listitem>
-<listitem>
-<simpara>required runtime library IDs and</simpara>
-</listitem>
-<listitem>
-<simpara>extended runtime environment ID.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>The N4JS method is the following:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>We consider only those changed deltas which represent an actual change (<literal>IResourceDescription.Delta#haveEObjectDescriptionsChanged()</literal>) and have a valid file extension (<literal>.n4js</literal>, <literal>.n4jsd</literal> or <literal>.js</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>For each <literal>candidate</literal>, we calculate the imported FQNs. The imported FQNs includes indirectly imported names besides the directly imported ones. Indirectly imported FQNs are, for instance, the FQNs of all transitively extended super class names of a direct reference.</simpara>
-</listitem>
-<listitem>
-<simpara>We state that a <literal>candidate</literal> is affected if there is a dependency (for example name imported by a <literal>candidate</literal>) to any name exported by the description from a delta. That is, it computes if a candidate (with given <literal>importedNames</literal>) is affected by a change represented by the description from the delta.</simpara>
-</listitem>
-<listitem>
-<simpara>If a <literal>candidate</literal> is affected we have to do an additional dependency check due to the lack of distinct unique FQNs. If a project containing the delta equals with the project contained by the candidate, or if the project containing the candidate has a direct dependency to the project containing the delta, we mark a candidate as affected.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>If a candidate was marked as affected, it will be removed from the <literal>allRemainingURIs</literal> and will be added to the build queue.</simpara>
-</listitem>
-<listitem>
-<simpara>If a candidate has been removed from the <literal>allRemainingURIs</literal> and queued for the build, we assume its <literal>TModule</literal> information stored in the user data is obsolete. To invalidate the obsolete information, we wrap the delta in the custom resource description delta so whenever the <literal>TModule</literal> information is asked for, it will be missing. We then register this wrapped delta into the copied Xtext index, end the builder state for the actual project then invoke the Xtext builder with the next dependent project.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-<section xml:id="sec:Incremental_Builder_Overview__Example">
-<title>Example</title>
-<simpara>To conclude this section, we briefly describe the state of the above five phases through a simple example. Assume a
-workspace with four N4JS projects: <emphasis>P1</emphasis>, <emphasis>P2</emphasis>, <emphasis>P3</emphasis> and <emphasis>PX</emphasis>. Each project has one single module with one single
-publicly visible class. Also let’s assume project <emphasis>P2</emphasis> depends on <emphasis>P1</emphasis> and <emphasis>P3</emphasis> depends on <emphasis>P2</emphasis>. Project <emphasis>PX</emphasis> have
-no dependencies to other projects. Project <emphasis>P1</emphasis> has a module <emphasis>A.n4js</emphasis> with a class <literal>A</literal>, project <emphasis>P2</emphasis> has one single
-module <emphasis>B.n4js</emphasis>. This module has a public exported class <literal>B</literal> which extends class <literal>A</literal>. Furthermore, project <emphasis>P3</emphasis> has
-one single module: <emphasis>C.n4js</emphasis>. This module contains one exported public class <literal>C</literal> which extends <literal>B</literal>. Finally, project
-<emphasis>PX</emphasis> has a module <emphasis>X.n4js</emphasis> containing a class <literal>X</literal> that has no dependencies to any other classes. The figure below
-picture depicts the dependencies between the projects, the modules and the classes as described above.</simpara>
-<figure role="center">
-<title>Builder State Example</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/builderStateExample.png"/>
-</imageobject>
-<textobject><phrase>builderStateExample</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>For the sake of simplification, the table below describes a symbol table for all resources:</simpara>
-<table frame="all" rowsep="1" colsep="1">
-<title>Resource Symbol Table</title>
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="50*"/>
-<colspec colname="col_2" colwidth="50*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara>P1/src/A.n4js</simpara></entry>
-<entry align="left" valign="top"><simpara>A</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>P2/src/B.n4js</simpara></entry>
-<entry align="left" valign="top"><simpara>B</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>P3/src/C.n4js</simpara></entry>
-<entry align="left" valign="top"><simpara>C</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>PX/src/X.n4js</simpara></entry>
-<entry align="left" valign="top"><simpara>X</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara>Let assume auto-build is enabled and the workspace contains no errors and/or warnings. We make one simple modification
-and expect one single validation error in class <literal>C</literal> after the incremental builder finished its processing; we delete the
-method <literal>foo()</literal> from class <literal>A</literal>.</simpara>
-<simpara>After deleting the method in the editor and saving the editor content, a workspace modification operation will run and
-that will trigger an auto-build job. The auto-build job will try to build the container project <emphasis>P1</emphasis> of module <emphasis>A</emphasis>. Since
-the project is configured with the Xtext builder command, a builder state update will be performed through the Xtext builder.
-Initially, due to an Eclipse resource change event (we literally modify the resource from the editor and save it), the
-<literal>ToBeBuilt</literal> instance wrapped into the <literal>BuildData</literal> will contain the URI of the module <emphasis>A</emphasis> marked for an update. When updating
-the copied index content, module <emphasis>A</emphasis> will be queued for a build. While processing the queued elements for project <emphasis>P1</emphasis>,
-module <emphasis>A</emphasis> will be processed and will be added to the <literal>allDeltas</literal> set. Besides that, it will be added to the <literal>changedDeltas</literal>
-set as well. That is correct, because its <literal>TModule</literal> information has been changed after deleting the public <literal>foo()</literal> method.
-When queuing affected resources, iterating through the set of <literal>allRemainingURIs</literal>, we recognize that module <emphasis>B</emphasis> is affected.
-That is indeed true; module <emphasis>B</emphasis> imports the qualified name of class <literal>A</literal> from module <emphasis>A</emphasis> and project <emphasis>P2</emphasis> has a direct
-dependency to <emphasis>P1</emphasis>. In this builder state phase, when building project <emphasis>P1</emphasis>, module <emphasis>C</emphasis> is not considered as affected.
-Although class <literal>C</literal> from module <emphasis>C</emphasis> also imports the qualified name of class <literal>A</literal> from module <emphasis>A</emphasis>, project <emphasis>P3</emphasis> does not
-have a direct dependency to project <emphasis>P1</emphasis>. When module <emphasis>B</emphasis> becomes enqueued for a forthcoming build phase, we assume its
-<literal>TModule</literal> information is obsolete. We invalidate this <literal>TModule</literal> related user data information on the resource description
-by wrapping the resource description into a custom implementation (<literal>ResourceDescriptionWithoutModuleUserData</literal>). Due to this
-wrapping the resource description for module <emphasis>B</emphasis> will be marked as changed (<literal>IResourceDescription.Delta#haveEObjectDescriptionsChanged()</literal>)
-whenever the old and current states are being compared.</simpara>
-<simpara>The Eclipse builder will recognize (via <literal>IProjectDescription#getDynamicReferences()</literal>) that project <emphasis>P2</emphasis> depends on project <emphasis>P1</emphasis>
-so the Xtext builder will run for project <emphasis>P2</emphasis> as well. At the previous phase we have enqueued module <emphasis>B</emphasis> for the build.
-We will therefore run into a builder state update again. We do not have any resource changes this time, so <literal>ToBeBuilt</literal> will
-be empty. Since <literal>ToBeBuilt</literal> is empty, we do not have to update the copied Xtext index state before the builder state setup
-phase. As the result of the previous builder state, phase module <emphasis>B</emphasis> is already enqueued for a build. When processing <emphasis>B</emphasis>
-we register it into the <literal>allDeltas</literal> set. That happens for each resource being processed by the builder state. But it will be
-registered into the <literal>changedDeltas</literal> because we have previously wrapped module <emphasis>B</emphasis> into a customized resource description delta
-to hide its obsolete <literal>TModule</literal> related user data information. Based on the builder state rules and logic described above,
-module <emphasis>C</emphasis> will be marked as an affected resource, will be queued for build and will be wrapped into a customized resource
-description delta to hide its <literal>TModule</literal> related user data information.</simpara>
-<simpara>In the next builder state phase, when building project <emphasis>P3</emphasis>, we apply the same logic as we applied for project <emphasis>P2</emphasis>. The
-builder state will process module <emphasis>C</emphasis> and will update the Xtext index state. No additional resources will be found as
-affected ones, nothing will be queued for build. The build will terminate, since there were no changed <literal>IResource</literal> instances
-and the build queue is empty.</simpara>
-<simpara>The outcome of the incremental build will be a workspace that contains exactly one validation error. The error will be
-associated with module <emphasis>C</emphasis> which was exactly our expectation, however, we have to clarify that transitive <emphasis>C</emphasis> dependency
-was built due to wrong reasons. Module <emphasis>C</emphasis> was build because we wrapped module <emphasis>B</emphasis> to hide its user data information and
-not because it imports and uses class <literal>A</literal> from module <emphasis>A</emphasis> which should be the logical and correct reason.</simpara>
-</section>
-</section>
-<section xml:id="dirty-state-handling" role="language-n4js">
-<title>Dirty state handling</title>
-<simpara>When two or more (N4)JS files are opened in editors and one of them is changed but without persisting this change the other
-open editors should be notified and if this change breaks (or heals) references in one of the other open resources their editors
-should updated so that warn and error markers are removed or added accordingly.</simpara>
-<simpara>When there are changes in the currently open editor these changes are propagated to all other open editors. Each Xtext editor has
-got its own resource set. The <literal>N4JSUpdateEditorStateJob</literal> runs for each open editor different from the editor where the changes have
-been made. In those editors the affected resources are unloaded and removed from the resource set. Then the Xtext resource of
-these editors is reparsed. After reparsing scoping and linking is invoked again, but now the references resources are rebuild
-as <literal>EObjectDescription</literal>s. The <literal>N4JSResource</literal> holds its own content that only contains 1..n slots when proxified.
-<literal>N4JSTypeScope.getSingleElement</literal> (called when resolving cross references and the linked element should be returned) will return the
-<literal>EObjectDescription</literal> created from the <literal>ModuleAwareContentsList</literal> in <literal>N4JSResource</literal>, that contains the first slot as proxy and the other
-slots as types. <xref linkend="fig:dirty_state_handling1"/> shows the flow to trigger the <literal>N4JSUpdateEditorStateJob</literal> and <xref linkend="fig:dirty_state_handling2"/>
-shows the sequence logic of the <literal>N4JSUpdateEditorStateJob</literal> in detail.</simpara>
-<figure xml:id="fig:dirty_state_handling1" role="center">
-<title>Sequence Diagram: Dirty State, Trigger <literal>N4JSUpdateEditorStateJob</literal></title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/dirty_state_handling1.png"/>
-</imageobject>
-<textobject><phrase>dirty state handling1</phrase></textobject>
-</mediaobject>
-</figure>
-<figure xml:id="fig:dirty_state_handling2" role="center">
-<title>Sequence Diagram: Dirty State, <literal>N4JSUpdateEditorStateJob</literal> in Detail</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/dirty_state_handling2.png"/>
-</imageobject>
-<textobject><phrase>dirty state handling2</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>A concrete example should illustrate the behaviour of the dirty state handling in conjunction with fully and partial loading
-of resources:</simpara>
-<simpara>Let A.js as above, and B.js as follows:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import A from "A.js"
-export class B {}</programlisting>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>assume is opened and loaded: is created with</simpara>
-<itemizedlist>
-<listitem>
-<simpara>is filled with a special proxy to resolve the <link linkend="AC">AST</link> of A only if needed.</simpara>
-</listitem>
-<listitem>
-<simpara>will be set to type A, loaded from <literal>EObjectDescription</literal> of A.js/A</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><link linkend="AC">AST</link> of A.js is to be accessed, e.g., for displaying JSDoc. A.js is not opened in an editor! is modified as follows:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>is filled with <link linkend="AC">AST</link>, i.e. proxy in 0 is resolved</simpara>
-</listitem>
-<listitem>
-<simpara>is updated with parsed type: 1) proxify , 2) unload (remove from content), 3) reload with parsed types again</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Assume now that A.js is opened and edited by the user.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Reconceiler replaces with modified <link linkend="AC">AST</link></simpara>
-</listitem>
-<listitem>
-<simpara>LazyLinker updates </simpara>
-</listitem>
-<listitem>
-<simpara>is proxified</simpara>
-</listitem>
-<listitem>
-<simpara>B <literal>searches</literal> for A and finds updated </simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</orderedlist>
-<simpara><emphasis>Each opened Xtext editor has got its own resource set!</emphasis> Such a resource set contains the resource for the currently edited
-file in the first place. When starting editing the file, the resource is reparsed , reloaded and linking (resolving the cross
-references) is done. By resolving the cross references <literal>N4JSTypeScope</literal> is used and now the URIs of the linked elements are belonging
-to resources not contained in the resource set of the editor so these resources a create in the resource set and their contents
-is loaded from the resource descriptions via
-<literal>N4JSResource.loadFromDescription</literal> .</simpara>
-<simpara>When the resource content is loaded from the existing resource description available from Xtext index the first slot is set to be
-a proxy with name <literal>#:astProxy</literal>.
-After that for all exported EObject descriptions of that resource description the user data is fetched and deserialized to types
-and these types are added to the slots of the resource in order they were exported. But the order is not that important anymore.</simpara>
-<simpara>As the resource set for the editor is configured to use the DirtyStateManager ( <literal>ExternalContentSupport.configureResourceSet(resourceSet, dirtyStateManager)</literal> ),
-all other open editors will be notified by changes in the current editor. This is done by <literal>N4JSDirtyStateEditorSupport</literal> that schedules
-a <literal>N4JSUpdateEditorStateJob</literal> that create a new resource description change event.</simpara>
-<simpara>Via <literal>isAffected</literal> and <literal>ResourceDescription.getImportedNames</literal> it is determine if a change in another resource affects this resource.</simpara>
-<simpara>Before loading the resource always <literal>N4JSDerivedStateComputer.installDerivedState</literal> is execute that, as we learned earlier, is responsible
-for creating the types in the resource.</simpara>
-<simpara>On every change to a N4JS file that requires a reparse the <literal>N4JSDerivedStateComputer.discardDerivedState</literal> is executed. This method do an
-unload on every root element at the positions 1 to n. In the <literal>N4JSUnloader</literal> all contents of the this root elements are proxified (i.e.
-there is a proxy URI set to each of them) and the references to the <link linkend="AC">AST</link> are set to null (to avoid notifications causing
-concurrent model changes). The proxification indicates for all callers of these elements, that they have to reload them. Afterwards
-it discards the complete content of the resource. The content is build up again with the reparse of the N4JS file content.</simpara>
-<simpara>As each editor has its own resource set, only the resource belonging to the current editor is fully loaded. All other referenced
-resources are only partially loaded, i.e. only the slot 1 of these resources are loaded (i.e. the types model elements) in this
-resource set. Linking is done only against these types model elements. Synchronization between the resource sets of multiple open
-editors is done via update job as described above.</simpara>
-<section xml:id="use-case-restoring-types-from-user-data">
-<title>Use case: Restoring types from user data</title>
-<itemizedlist>
-<listitem>
-<simpara>Use case: referencing resources in editor: This has been described already in context of dirty state handling</simpara>
-</listitem>
-<listitem>
-<simpara>Use case: referencing resources from JAR: This is still to be implemented.% taskIDE-37</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="use-case-updating-the-xtext-index">
-<title>Use case: Updating the Xtext index</title>
-<simpara>When a N4JS file is changed in way that requires reparsing the file, the underlying resource is completely unloaded and loaded again.
-By this the also the elements at the Xtext index are recreated again, belonging to this resource (i.e. new entries for new elements
-in the resource, update index elements of changed elements, delete index entries for deleted elements).</simpara>
-<simpara>When Eclipse is closed the Xtext index is serialized in a file.</simpara>
-<informalfigure role="center">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/index_serialization.png"/>
-</imageobject>
-<textobject><phrase>index serialization</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>When starting Eclipse again, the Xtext index is restored from this file:</simpara>
-<informalfigure role="center">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/07_typeindex/images/loading_existing_index.png"/>
-</imageobject>
-<textobject><phrase>loading existing index</phrase></textobject>
-</mediaobject>
-</informalfigure>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_project-model">
-<title>Project Model</title>
-<section xml:id="sec:Package_json">
-<title>Package.json File</title>
-<simpara>See [<link linkend="N4JSSpec">N4JSSpec</link>] for the format specification of N4JS-specific package.json files.
-Based on the JSON-model-based AST that can be parsed from the package.json file, we transform the information that can be extracted into an instance of the N4JS-specific ProjectDescription model.
-This model is defined by means of EMF, the Xcore file is found in the N4JS model bundle.</simpara>
-<informalfigure xml:id="fig:projectDescriptionModel">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/08_projectModel/images/cd_projectDescription.svg"/>
-</imageobject>
-<textobject><phrase>Project Description Model</phrase></textobject>
-</mediaobject>
-</informalfigure>
-</section>
-<section xml:id="_accessing-project-information">
-<title>Accessing Project Information</title>
-<simpara>The information in the package.json files is parsed into memory at runtime, e.g. within Eclipse or in headless mode. It is made available via the <literal>IN4JSCore</literal> facade that provides a high-level abstraction when working with the project structure. This facade has two implementations:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>One implementation is backed by the file system, e.g. <literal>java.io.File</literal> and used in a headless environment</simpara>
-</listitem>
-<listitem>
-<simpara>Another implementation uses the Eclipse resource model (<literal>IProject</literal>, <literal>IFolder</literal>, <literal>IFile</literal>) to describe the contents of an <literal>IN4JSProject</literal>. This implementation is automatically kept in sync whenever the contents of a package.json file is edited by a user. It is also maintained as dynamic project information to make the Eclipse workspace aware of the declared dependencies. That is, Eclipse projects know about the project references in the package.json file.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The project model is mimicing the handle based services of Eclipse’s <literal>JavaCore</literal>, the handles are often represented as EMF <literal>URIs</literal> though. Therefore the API allows to retrieve a source folder for a given N4JS resource, all the libraries that are configured for a project or simply the project’s name or the information if it exists. Subsequent components in the processing chain like the scope provider can leverage the API to deduce the container configuration and visiblity constraints. Project references are resolved transparently.</simpara>
-<simpara>The Xtext index participation is implemented by means of the <literal>N4JSToBeBuiltComputer</literal> and the <literal>N4JSAllContainersState</literal>. These classes provide access to the container configuration.</simpara>
-<simpara>The precedence for the dependency resolution follows this lookup chain:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>An accessible <literal>IN4JSProject</literal> with the given name is located in the workspace.</simpara>
-</listitem>
-<listitem>
-<simpara>The library manager provides access to the requested project.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Accordingly, the type lookup follows the same chain due to the container configuration that is deduced from the package.json configuration. Of course is prefers locally defined type that can be found in the current project over types that are located in referenced projects.</simpara>
-<section xml:id="sec:IN4JSCore">
-<title>IN4JSCore</title>
-<simpara>Facade analogous to org.eclipse.jdt.core.JavaCore.
-It is used look up the project or source container where a resource URI belongs to.
-It also provides some helper methods to retrieve information from the package.json file.
-N4JSRuntimeCore uses the file system and thus uses java.io to access files and folders.
-N4JSEclipseCore uses the Eclipse workspace and thus uses org.eclipse.resources API.
-Both Core implementations act as wrapper for N4JSModel resp. EclipseN4JSModel.
-Instances of the <literal>IN4JSCore</literal> are obtained as usually via dependency injection, e.g. <literal>@Inject IN4JSCore n4jsCore</literal>.</simpara>
-</section>
-<section xml:id="sec:N4JSModel">
-<title>N4JSModel</title>
-<simpara>N4JSModel uses FileBasedWorkspace to load and access the project description from the package.json file and create wrappers for projects (N4JSProject) and source containers (N4JSSourceContainer).</simpara>
-<simpara>A source container is a wrapper for a file system that has been marked as source folder in the package.json file.
-For determination of the current project a given EMF URI pointing to the project path is used.
-In N4JSModel this location is directly wrapped in N4JSProject.
-In N4JSModel a given EMF URI is resolved to a source container by using the specified relative source paths from the package.json file and file system based project location.
-If the EMF URI converted to a file URI starts with the absolute source folder path a N4JSProjectSourceContainer is created and returned for that EMF URI.</simpara>
-<simpara>In EclipseN4JSModel (that extends N4JSModel) the last segment of the URI is assumed to be the project name and via the EclipseBasedN4JSWorkspace that wraps the Eclipse workspace a project with that name is tried to be resolved.
-This IProject is than wrapped in N4JSEclipseProject.
-In EclipseN4JSModel a given EMF URI is resolved to an org.eclipse.core.resources.IResource belonging to the IWorkspaceRoot.
-That resource is wrapped in EclipseSourceContainer.</simpara>
-<simpara>N4JSModel is also used to retrieve project dependencies wrapped as N4JSProject.</simpara>
-</section>
-<section xml:id="sec:N4JSWorkspace">
-<title>N4JSWorkspace</title>
-<simpara>The FileBasedWorkspace and EclipseBasedN4JSWorkspace should only be accessed by N4JSModel resp. EclipseN4JSModel as they know the contract for the URI scheme.
-The FileBasedWorkspace creates AbstractTreeIterator for the direct contents of a source container, so that their children can be navigated by this as well.
-It then filters out all directories and returns an iterator of all files as EMF URIs.</simpara>
-<simpara>The EclipseBasedN4JSWorkspace wraps the IWorkspaceRoot.</simpara>
-<simpara>Fetching the project description read out from the package.json file is cached in both workspace implementations.
-In FileBasedWorkspace the LazyProjectDescriptionHandle is used as proxy and in EclipseBasedN4JSWorkspace the ProjectDescriptionLoadListener is used to invalidate the cache when the package.json file has been changed.
-ProjectDescriptionLoadListener also ensures that dependent projects are considered by the Eclipse builder by setting dynamic dependencies in the project meta data.
-It also updates these project dependencies if it is required and recalculates all source containers.</simpara>
-<simpara>In the tests another implementation, MockWorkspace, is used, that provides a dummy project description.</simpara>
-</section>
-<section xml:id="sec:N4JSProject">
-<title>N4JSProject</title>
-<simpara>A N4JSProject represents a configured project as defined in the package.json file.
-So in principles it wraps access to N4JSModel (and so to containing source containers, libraries and so on)
-and to some information from the package.json file directly (like defined module filters, vendorId and others).
-It is also used to compare depending projects.</simpara>
-<simpara>N4JSProject is the runtime representation while N4JSEclipseProject represents a project in the Eclipse workspace.
-N4JSProject is identified by its EMF location URI while N4JSEclipseProject wraps the underlying org.eclipse.core.resources.IProject.</simpara>
-<simpara>In tests MockProject is used.</simpara>
-</section>
-<section xml:id="sec:SourceContainer">
-<title>SourceContainer</title>
-<simpara>A source container contains either source files for production, tests or external declarations.
-By default all these files resp. their containing types will be exported to the Xtext index.
-A source container belongs exactly to one project it is identified by its project relative location.</simpara>
-<simpara>A N4JSProjectSourceContainer is a container that contains unpacked n4js, js and n4jsd files that can be modified.
-By default all these files are syntactically and semantically validated (this can be configured by the use of module filters).
-Except for n4jsd files, all files are compiled by the configured compilers.</simpara>
-<simpara>EclipseSourceContainer specializes N4JSProjectSourceContainer to work on top of the Eclipse resources API.
-Thus besides the location it also wraps the IFolder.</simpara>
-<simpara>The IFile was chosen instead of using the java.io.File because changes to an IFile (and IResource in general) trigger a workspace change event so that the Xtext builder is triggered properly.</simpara>
-</section>
-<section xml:id="sec:N4JSProjectsStateHelper">
-<title>N4JSProjectsStateHelper</title>
-<simpara>Calculates the visible containers for a given container, where containers are source containers within the project as well as source containers of other depending projects in workspace.
-The calculated handles are cached and invalidated if the project description file has changed or the project has been closed or reopened.</simpara>
-</section>
-</section>
-<section xml:id="sec:Caching">
-<title>Caching</title>
-<simpara>Caching is heavily used in the ExternalLibraryWorkspace and the N4JSProjectsStateHelper.
-The ExternalLibraryWorkspace relies on caching to provide data about all installed npms, their locations, names, shadowing, dependencies and so on.
-The caching of the ExternalLibraryWorkspace is implemented in the ExternalProjectMappings which inspects all external locations and builds all necessary mappings.
-The set of mappings start from a simple list of all npms, include mappings that map from location or name to a N4JSExternalProject, or give reduced set of projects.</simpara>
-<section xml:id="_caching-of-externallibraryworkspace">
-<title>Caching of ExternalLibraryWorkspace</title>
-<simpara>A reduced set of projects is used since not all npms are actually necessary projects for the N4JS IDE.
-Most transitively installed plain-JS npms are of no interest since they are completely invisible to the user.
-The reduced set of projects always consists of all user workspace projects and all shipped libraries.
-From the set of all installed npms, only those are necessary that are dependencies of a non-plain-JS projects.
-Shadowed projects are also not included in the reduced set of npms.</simpara>
-<simpara>To access projects that are not included in the reduced set of npms, the ExternalProjectMappings provides some collections that contain complete set of npms.
-Additionally, some mappings also provide information about not necessary npms.
-Note that mappings that use the project name as a key naturally cannot provide information about shadowed projects.</simpara>
-<simpara>The mapping cache is updated every time a refresh is triggered (e.g. at startup or by hitting F5).
-Also, every action of the library manager (such as installing or registering npms) triggers a refresh.</simpara>
-</section>
-<section xml:id="_caching-of-n4jsprojectsstatehelper">
-<title>Caching of N4JSProjectsStateHelper</title>
-<simpara>The N4JSProjectsStateHelper uses the MultiCleartriggerCache for caching information about projects of the user workspace.
-The EclipseBasedN4JSWorkspace does not caching at all, but provides information about project descriptions which is expensive to compute on the fly.
-Hence this information is cached in the MultiCleartriggerCache and updated every time a project description changes, is added or removed.</simpara>
-<simpara>Sometimes, a project description is rendered invalid as a side effect of a change on another project description.
-In this case, the cache of both of project descriptions has to be updated.
-The implementation to cope with these side effects uses the MultiCleartriggerCache which allows to set multiple triggers that will clear a cached object.</simpara>
-<simpara>However, it seems reasonable to align the caching of the user workspace to the caching of the external workspace.
-The reason is that caching of user workspace information such as N4JSProjects would increase build performance significantly.
-This is since as of now, projects (and information about all their source containers) is computed on the fly, that causes thousands of expensive calls to the file system.</simpara>
-</section>
-</section>
-<section xml:id="sec:WildcardPathFilter">
-<title>WildcardPathFilter</title>
-<simpara>This class encapsulates the logic to resolve (wildcard containing) paths against the file system.
-With the method matchPath it is also possible to resolve a path without using the file system.
-This class is also able to resolve relative navigation in paths.</simpara>
-</section>
-<section xml:id="sec:ProjectUtils">
-<title>ProjectUtils</title>
-<simpara>ProjectUtils provides additional methods for providing information only required in compilation, e.g. like file and module descriptor.
-It uses IN4JSCore to retrieve the information of output path and whether module wrapping is required for a given file.</simpara>
-</section>
-</chapter>
-<chapter xml:id="_binding">
-<title>Binding</title>
-<warning>
-<simpara>This section may be outdated!</simpara>
-</warning>
-<section xml:id="sec:Binding_Design_Rationale" role="language-n4js">
-<title>Design Rationale</title>
-<simpara>Binding references to declarations follows the Xtext mechanism based on local <literal>N4JSScopeProvider</literal> and a global <literal>N4JSGlobalScopeProvider</literal> scope providers. The basic question is: to which elements are references bound to. This in particular interesting for all kind of type declarations, including functions as they are interpreted as types. These declarations are Janus-faced: On the one side, they are targets of type references as <literal>Type</literal>, and on the other side they can also be target of identifier references bound to some so called <literal>IdentifiableElement</literal>. As explained in <xref linkend="_type_index"/>, special type objects (<literal>TClass</literal> etc.) are created from the original declarations. These type objects are used as targets for both kind of references. The following table summarizes the reference-target relations relevant for N4JS (not the standalone type grammar).</simpara>
-<table frame="all" rowsep="1" colsep="1">
-<title>N4JS Cross References</title>
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="50*"/>
-<colspec colname="col_2" colwidth="50*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Reference</entry>
-<entry align="left" valign="top">Target Type</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara><emphasis role="strong">N4JS</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ImportDeclaration.importedModule</simpara></entry>
-<entry align="left" valign="top"><simpara>TModule</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>NamedImportSpecifier.importedElement</simpara></entry>
-<entry align="left" valign="top"><simpara>types.IdentifiableElement</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>IdentifierRef.id</simpara></entry>
-<entry align="left" valign="top"><simpara>types.IdentifiableElement</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ParameterizedPropertyAccessExpression.property</simpara></entry>
-<entry align="left" valign="top"><simpara>types.TMethod</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>PropertyAccessExpression.property</simpara></entry>
-<entry align="left" valign="top"><simpara>types.TMember</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>N4Getter/N4SetterDeclaration.field</simpara></entry>
-<entry align="left" valign="top"><simpara>N4FieldDeclaration</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>Continue/Break-Statement.label</simpara></entry>
-<entry align="left" valign="top"><simpara>LabelledStatement</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top" namest="col_1" nameend="col_2"><simpara>Type Expressions</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ParameterizedTypeRef.declaredType</simpara></entry>
-<entry align="left" valign="top"><simpara>Type</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara><xref linkend="fig:cd_scoping"/> gives an overview over the most important classes in the scoping package, with the <literal>N4JSScopeProvider</literal> and the used customized scopes created by the scope providers.</simpara>
-<figure xml:id="fig:cd_scoping" role="center">
-<title>Overview Scoping Package</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/09_binding/images/cd_scoping.svg"/>
-</imageobject>
-<textobject><phrase>cd scoping</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:Binding_to_Members" role="language-n4js">
-<title>Binding to Members</title>
-<simpara>Members of different types, such as classes and also record types or enumerations, are bound using the <literal>MemberScopeProvider</literal>. This often returns a <literal>MemberScope</literal>, which directly works on the members. Most types with members are implemented by subclasses of <literal>ContainerType</literal>, using <literal>CollectMembersHelper</literal> to collect all members and <literal>FindMemberHelper</literal> for retrieving a member by its name via <literal>ContainerTypes</literal>. Ensure that when types with members are added to override appropriate methods in all of these related classes (e.g., <literal>CollectMembersHelper</literal>, <literal>AbstractHierachyTraverser</literal> and <literal>FindMemberHelper</literal> uses polymorphic dispatch to handle different subtypes – so you won’t be able to find a member if you do not adjust these helpers).</simpara>
-</section>
-<section xml:id="sec:Binding_Getter_Setter">
-<title>Getter / Setter Binding</title>
-<simpara>For customized binding of getters / setters, see <link linkend="sec:Field_Accessors">Accessors</link>.</simpara>
-</section>
-<section xml:id="chap:Statics">
-<title>Static Member Binding</title>
-<simpara>For customized binding of static members, see <link linkend="sec:Static_Members">Static Members</link>.</simpara>
-</section>
-<section xml:id="sec:Binding_Enumeration">
-<title>Enumeration Literals Binding</title>
-<itemizedlist>
-<listitem>
-<simpara>introduced new type ref EnumTypeRef: it behaves comparable to ClassifierTypeRef, but with the difference that the MemberScopeProvider filters for a given EnumTypeRef filters all literals of the contained TEnum (in comparison the MemberScopeProvider filters for a given ClassifierTypeRef all static members of the contained classifier)</simpara>
-</listitem>
-<listitem>
-<simpara>it isn’t possible to access literals on a enumeration literal itself, although this literal is typed as TEnum (that contains TEnumLiterals)</simpara>
-</listitem>
-<listitem>
-<simpara>as there are currently no additional fields and operations for enumeration literals defined (in Java there is name and value()), the scope for literals is currently empty</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Accessibility_of_types_and_members" role="language-n4js">
-<title>Accessibility of types and members</title>
-<simpara>Member access and type access has to be constrained and validated against the accessibility rules of N4JS. Therefore, the scoping annotates certain elements as erroneous to detect invalid references.</simpara>
-<simpara>Basically two different approaches are used to implement that behavior:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The <literal>VisibilityAwareTypeScope</literal> and <literal>VisibilityAwareMemberScope</literal> decorate an existing scope to validate the result on access. This allows to lazily check the visibility of the returned element. If it is not accessible, it is wrapped in a <literal>AbstractDescriptionWithError</literal> which will be indentified as such by the <literal>ErrorAwareLinkingService</literal>. Before the binding is resolved and the EMF proxy is replaced, the error message is used to create an EMF diagnostic.</simpara>
-</listitem>
-<listitem>
-<simpara>For other cases, the scopes are produced differently, e.g. if all elements are easily enumerable and have to be collected before the scope is created (e.g. for imported elements), the scoped elements are validated eagerly to put them into the correct layer of scopes. That is, the valid descriptions may shadow the invalid description. Since there are more error conditions for these cases, e.g. duplicate imports and similar cases, the accessibility is checked before the concrete member is accessed. All the instances <literal>AbstractDescriptionWithError</literal> are put into the <literal>MapBasedScope</literal> immediately.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>In that sense, accessibility checks are basically implemented as decorators for the scoping itself. Bindings are established but flagged as errors.</simpara>
-<simpara>Default visibility of members is calculated in <literal>Types.xcore</literal> (in <literal>getTypeAccessModifier</literal> and <literal>getMemberAccessModifier</literal> etc.). Visibility is checked in <literal>org.eclipse.n4js.scoping.accessModifiers.MemberVisibilityChecker</literal> and validators.</simpara>
-</section>
-<section xml:id="sec:Member_Scope_Example" role="language-n4js">
-<title>Member Scope Example</title>
-<simpara>In this section, we are going to have a look at the creation process of <literal>MemberScope</literal>.</simpara>
-<formalpara>
-<title>C.n4js</title>
-<para>
-<screen>export public class C {
- private m1: int;
- public m2: int;
-}</screen>
-</para>
-</formalpara>
-<formalpara>
-<title>Test.n4js</title>
-<para>
-<screen>import { C } from "C";
-
-let c: C = new C();
-c.m1; // Error -> The field m1 is not visible
-c.m2; // OK -> m2 is visible at this context</screen>
-</para>
-</formalpara>
-<simpara>Assume that we need to figure out to which element the <literal>ParameterizedPropertyAccessExpression c.m1</literal> in the <literal>ExpressionStatement c.m1</literal> binds to. To answer this question, <literal>N4JSScopeProvider.getScope(context, reference)</literal> is triggered whereby <literal>context</literal> is the <literal>ParameterizedPropertyAccessExpression</literal> and <literal>reference</literal> is <literal>EReference property</literal> (<literal>property</literal> is the cross-reference element defined in <literal>ParameterizedPropertyAccessExpression</literal> 's grammar).</simpara>
-<simpara><literal>N4JSScopeProvider.getScope(context, reference)</literal> does not implement the scoping but delegates to corresponding methods based on the type of <literal>context</literal>. In our example, since <literal>context</literal> is a <literal>ParameterizedPropertyAccessExpression</literal>, the scoping logic is delegated to the method that creates a <emphasis role="strong">MemberScope</emphasis> for the context <literal>ParameterizedPropertyAccessExpression c.m1</literal> based on the receiver type of <literal>c</literal> which is class <literal>C</literal>.
-The resulting scope instance returned by <literal>N4JSScopeProvider.getScope()</literal> in our example is of type <literal>TypingStrategyAwareMemberScope</literal> as shown in <xref linkend="fig:memberscope-example"/> .</simpara>
-<figure xml:id="fig:memberscope-example">
-<title>Member scope hierarchy</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/09_binding/images/memberscope_example.svg" align="center"/>
-</imageobject>
-<textobject><phrase>memberscope example</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>In the hierarchy, the top-level scope is the NULL scope. Directly below the NULL scope is a MemberScope which contains all members of <literal>N4Object</literal> since the class <literal>C</literal> implicitly inherits <literal>N4Object</literal>. The other <literal>MemberScope</literal> instance beneath contains all members of the class <literal>C</literal> <emphasis role="strong">regardless of their visibility</emphasis>. These members are <literal>m1</literal> and <literal>m2</literal>. While <literal>m2</literal> is can be accessed by <literal>c.m2</literal>, <literal>m1</literal> it not visible at <literal>c.m1</literal>. The <literal>VisibilityAwareMemberScope</literal> implements precisely this behavior. In particular, it returns all members of <literal>C</literal> that are visible at the current <literal>context</literal> (here the element <literal>m2</literal>), while wrapping non-visible members (here the element <literal>m</literal>) in <literal>InvisibleMemberDescription</literal> instances. These <literal>InvisibleMemberDescription</literal> instances of type <literal>IEObjectDescriptionWithError</literal> contain issue code and error message related to accessibility problems and are recognized during the error-aware linking phase done by <literal>ErrorAwareLinkingService</literal>. It is worth to emphasize the motivation behind use of <literal>IEObjectDescriptionWithError</literal> is to provide more informative error messages to the user other than <emphasis>Cannot reference element…​</emphasis> Another example of <literal>IEObjectDescriptionWithError</literal> is <literal>WrongWriteAccessDescription</literal> that is used when we, try to write to a getter and no corresponding setter exists.</simpara>
-</section>
-<section xml:id="sec:Scoping_for_Members_of_Composed_Type_Explained" role="language-n4js">
-<title>Scoping for Members of Composed Type (Union/Intersection) Example</title>
-<simpara>In this section, we will have a look at how scoping is implemented for composed type, i.e. union or intersection type with an example of union type. Intersection is done similarly. Before reading this, it is strongly recommended to read <xref linkend="sec:Member_Scope_Example"/> first.</simpara>
-<formalpara>
-<title>Defs.n4js</title>
-<para>
-<screen>export public class C {
- private m1: int;
- public m2: int;
-}
-
-export public class D {
- private m1: int;
- get m2(): int { return 42; };
-}</screen>
-</para>
-</formalpara>
-<formalpara>
-<title>Test.n4js</title>
-<para>
-<screen>import { C, D } from "Defs";
-
-let cud : C|D;
-
-cud.m2 = 10;</screen>
-</para>
-</formalpara>
-<simpara>Assume that we need to find out to what element the <literal>ParameterizedPropertyAccessExpression cud.m2</literal> in the <literal>ExpressionStatement cud.m2</literal> binds to.
-This is a question for scoping. Since the receiver type of <literal>cud</literal> is a union type <literal>C|D</literal>, a <literal>UnionMemberScope</literal> is created that contains two subscopes, each of which corresponds to an individual type in the union. The resulting scope hierarchy is graphically depicted in <xref linkend="fig:unionmemberscope-example"/>.</simpara>
-<figure xml:id="fig:unionmemberscope-example">
-<title>Union member scope hierarchy</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/09_binding/images/unionmemberscope_example.svg" align="center"/>
-</imageobject>
-<textobject><phrase>unionmemberscope example</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The two subscopes are of type <literal>TypingStrategyAwareMemberScope</literal> and created exactly the same way as described in <xref linkend="sec:Member_Scope_Example"/>.
-The <literal>UnionMemberScope</literal> instance contains a list of subscopes for all types involved in the union and is responsible for constructing an <literal>IEObjectDescription</literal> instance for <literal>m2</literal> by merging all members of the name <literal>m2</literal> found in all subscopes.
-Merging members requires considering a variety of combinations (fields, setters getters, optional/variadic parameters etc.) and thus can become very complicated. To reduce the complexity, the recently refactored implementation splits the proccess into three separate steps.</simpara>
-<simpara>Step 1: Collect information</simpara>
-<simpara>During this phase, members with the name <literal>m2</literal> are looked up in each subscope and collected into an <literal>ComposedMemberInfo</literal> instance by <literal>ComposedMemberInfoBuilder</literal>.
-The first subscope (left branch in the <xref linkend="fig:unionmemberscope-example"/>) returns an <literal>EObjectDescription</literal> wrapping the <literal>TField m2</literal> of class <literal>C</literal> and hence <literal>TField m2</literal> is added to the <literal>ComposedMemberInfo</literal> instance. The second subscope (right branch in the <xref linkend="fig:unionmemberscope-example"/>) returns a <literal>WrongWriteAccessDescription</literal> wrapping the <literal>TGetter m2</literal> of class <literal>D</literal> and hence <literal>TGetter m2</literal> is added to <literal>ComposedMemberInfo</literal> instance. The reason for <literal>WrongWriteAccessDescription</literal> because <literal>cud.m2</literal> is trying to write to the getter of the same name in <literal>D</literal>.</simpara>
-<simpara>At the end of this step, two members <literal>public TField m2: int</literal> and <literal>project TGetter m2(): int</literal> are added to <literal>ComposedMemberInfo</literal>.</simpara>
-<simpara>Step 2: Merge members</simpara>
-<simpara>This phase merges members of the same name into a composed member based on the information about these members collected in Step 1. Note that merge rules can become quite complicated as many situations must be considered. Sometimes, it is not possible to merge at all. If the merge is possible, we need to consider the following properties, among others,</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Member kind: what kind of member is the merge result. For instance, what do we get when we merge a field with a setter?</simpara>
-</listitem>
-<listitem>
-<simpara>Type of merge member: What is the return/parameter type of the merge result?</simpara>
-</listitem>
-<listitem>
-<simpara>Accessibility: what is the accessibility of the merge result?</simpara>
-</listitem>
-<listitem>
-<simpara>Optionality/Variadic: Should a parameter of the merge be optional or variadic?</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The actual merge rules are implemented in the class <literal>UnionMemberFactory</literal> which delegates to either of the classes <literal>UnionMethodFactory</literal>, <literal>UnionFieldFactory</literal>, <literal>UnionGetterFactory</literal> and <literal>UnionSetterFactory</literal>.</simpara>
-<simpara>In our example,
-The merge result of <literal>public TField m2: int</literal> and <literal>project TGetter m2(): int</literal> are merged into a <literal>project TGetter m2: int</literal> .</simpara>
-<simpara>Step 3: Construct the scope entry</simpara>
-<simpara>In this final step, the actual IEObjectDescription for <literal>m2</literal> is constructed. In our example, since there exists one subscope exposing an <literal>EObjectDescriptionWithError</literal> (here <literal>WrongWriteAccessDescription</literal>), the final result is an instance of <literal>UnionMemberDescriptionWithError</literal>. This error instance is recognized during the linking phase and the error message of the subscope regarding <literal>WrongWriteAccessDescription</literal> is displayed: <emphasis>Union combines fields and getters with name m2 and therefore property m2 is read-only.</emphasis></simpara>
-<simpara>More details can be found in the API documentation in the code. A good starting point is the class <literal>ComposedMemberScope</literal>.</simpara>
-</section>
-<section xml:id="sec:Binding_of_Structurally_References_Types" role="language-n4js">
-<title>Structurally References Types</title>
-<simpara>Scoping of structurally referenced types is similar to binding of members. The structural typing modifier basically filters the members of a type. That is, the structural modifier filters out all non-public members, and the field-only modifier only accept fields. Thus, similar to accessibility aware scoping (<xref linkend="sec:Accessibility_of_types_and_members"/>), the <literal>TypingStrategyAwareMemberScope</literal> encapsulates an original scope and applies these additional filters.</simpara>
-<simpara>Bindings to additional members of a structurally referenced type is implemented in <literal>MemberScopeProvider.members(ParameterizedTypeRefStructural ..)</literal>. Note that the current implementation does not necessarily bind to the type model (TModule) instance, as these members are part of a type reference. That is, usually these bindings refer to the <link linkend="AC">AST</link> elements. Thus, it is not possible to compare these members directly, instead, a structural comparison has to be applied.</simpara>
-</section>
-<section xml:id="sec:Building">
-<title>Building</title>
-<section xml:id="sec:Build_Phases">
-<title>Build Phases</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Phase 0</simpara>
-</entry>
-<entry>
-<simpara>Loading Resources</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Phase 1: prelinking</simpara>
-</entry>
-<entry>
-<simpara>Create symbols for all resources, includes creation of temporary pre-linked type models</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Phase 2: linking</simpara>
-</entry>
-<entry>
-<simpara>Resolve all links, includes fully-resolved typed models<?asciidoc-br?>
-includes compilation</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>That is, not each resource is loaded, pre-linked and linked separately. Instead, all resources are first loaded, then all resources are pre -inked, and only then all resources are linked.</simpara>
-</section>
-<section xml:id="sec:Build_Scenarios">
-<title>Build Scenarios</title>
-<simpara>Consequences:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>do not try to set any types in types builder, only create symbols there (probably not even members of types)</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Lazy_linking_problem">
-<title>Lazy linking problem</title>
-<simpara>Lazy linking proxies in the indes may trigger reloading of AST (which leads to invalid disconnected type models):</simpara>
-<simpara>Lazy links (ending with |x in which x is an index entry of a temporary list used to resolve the link) must not be written into index.</simpara>
-</section>
-</section>
-<section xml:id="sec:Proxies_and_Proxy_Resolution" role="language-n4js">
-<title>Proxies and Proxy Resolution (Overview)</title>
-<simpara>Here we give a brief overview of the different kinds of proxies and when / how they are created and resolved.</simpara>
-<section xml:id="xtexts-lazy-linking-proxies">
-<title>Xtext’s Lazy Linking Proxies</title>
-<itemizedlist>
-<listitem>
-<simpara>URI fragment is <literal>|</literal> <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi></math> (where <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi></math> is a non-negative integer).<?asciidoc-br?>
-<literal>platform:/resource/Project/src/A.n4js#|3</literal></simpara>
-</listitem>
-<listitem>
-<simpara>created by Xtext’s <literal>LazyLinkingResource</literal> in the AST after parsing (they are only ever created in the AST, but the types builder may copy them to the TModule, so they may appear there as well.</simpara>
-</listitem>
-<listitem>
-<simpara>used to represent cross-references defined in the source code (i.e. name of an identifiable element used in source code to refer to that element).<?asciidoc-br?></simpara>
-<simpara>Since the types builder sometimes copies proxies from AST to TModule (e.g. type of an element that was provided with an explicit type declaration in the source code), these proxies may also appear in the TModule, but only between the types builder phase and the end of the post-processing phase (or later, in case they are unresolvable).</simpara>
-</listitem>
-<listitem>
-<simpara>resolution is handled by <literal>#getEObject(String)</literal> in <literal>LazyLinkingResource</literal>, which recognizes lazy linking URI fragments and then forwards them to <literal>#getEObject(String,Triple)</literal>, which in turn relies on the Xtext infrastructure.</simpara>
-</listitem>
-<listitem>
-<simpara>latest time of resolution: post processing. After post processing has completed, they should all be gone (unless they are unresolvable, e.g. typo in source code).</simpara>
-</listitem>
-<listitem>
-<simpara>fun facts:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the number after the pipe character is the index of a <literal>Triple</literal> stored in field <literal>proxyInformation</literal> in each <literal>LazyLinkingResource</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>the resource given before the fragment (e.g. <literal>A.n4js</literal> in the above example) is not the resource the proxy is pointing to (i.e. the resource containing the target EObject), but the resource from where the link originates.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="standard-emf-proxies">
-<title>Standard EMF Proxies</title>
-<itemizedlist>
-<listitem>
-<simpara>URI fragment contains a path to an EObject, using reference names and indices:<?asciidoc-br?>
-<literal>platform:/resource/Project/src/A.n4js#/1/@topLevelTypes.1/@ownedMembers.0</literal></simpara>
-</listitem>
-<listitem>
-<simpara>created automatically by EMF</simpara>
-<itemizedlist>
-<listitem>
-<simpara>during deserialization of a TModule <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math> from the Xtext index for all references to a different TModule <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math> (see <literal>UserdataMapper</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>when unloading a resource.</simpara>
-</listitem>
-<listitem>
-<simpara>…​</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>used to represent</simpara>
-<itemizedlist>
-<listitem>
-<simpara>cross-references from one TModule to another TModule.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>astElement</literal> links from TModule to AST whenever the AST is not present (e.g. resource was loaded from Xtext index).</simpara>
-</listitem>
-<listitem>
-<simpara><literal>definedType</literal> links from AST to TModule after deleting the TModule (this happens in the incremental builder after the pre-linking phase).</simpara>
-</listitem>
-<listitem>
-<simpara>all kinds of links after demand-loading an AST by resolving an <literal>astElement</literal> link (pathological case).</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>resolution is handled in two ways:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>if the context <literal>EObject</literal> of the proxy, i.e. the one where the proxified cross-reference originates, is contained in an N4JSResource <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math>, then resolution is handled by <literal>N4JSResource#doResolveProxy()</literal> (see also <literal>ProxyResolvingResource</literal> for details).</simpara>
-<simpara>In this case, special handling is performed to make sure that (a) the target resource is loaded from the index, if possible, and (b) post-processing of the target resource is initiated iff the target resource was loaded from AST (instead from the Xtext index) AND post-processing of resource <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> is currently in progress or has already been completed.</simpara>
-</listitem>
-<listitem>
-<simpara>otherwise, resolution is handled by standard EMF functionality.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>latest time of resolution: none. In fact, some of those proxies (those representing <literal>astElement</literal> links from TModule to AST) must not be resolved at all, because this is not yet properly handled.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_how-is-proxy-resolution-triggered">
-<title>How is Proxy Resolution Triggered?</title>
-<simpara>Resolution of proxies throughout the N4JS implementation is triggered as usually when using EMF, which means: whenever the getter of a EMF cross-reference is invoked and the value is still a proxy, the EMF-generated code of the getter will automatically trigger resolution of this proxy. For details look at the EMF-generated code of the getter of any cross-reference (<literal>IdentifierRefImpl#getId()</literal> would be a good example).</simpara>
-</section>
-<section xml:id="_when-is-proxy-resolution-allowed">
-<title>When is Proxy Resolution Allowed?</title>
-<simpara>So, at what time is it legal to trigger such a proxy resolution? Or, more concretely, during which resource load states (<xref linkend="sec:N4JS_Resource_Load_States"/>) is it legal to trigger proxy resolution? In fact, asking the question in this way is incorrect or at least not very helpful, because the answer would be (almost) always. The better question is: which components of the system / which parts of the code base are allowed to trigger proxy resolution?</simpara>
-<simpara>For example, triggering resolution is disallowed in the <literal>ASTStructureValidator</literal> and <literal>N4JSTypesBuilder</literal>, but for the outside client code such as a JUnit test it is allowed to trigger proxy resolution as early as right after parsing. For an example of the latter see test <literal>#testStateFullyProcessed_triggeredOnlyThroughProxyResolution()</literal> in <literal>N4JSResourceLoadStatesTest</literal>.</simpara>
-<simpara>In summary, we can state the rule that the <emphasis role="strong">internal N4JS implementation</emphasis> must not trigger any proxy resolution until installation of the derived state has completed, i.e. not before resource load state "Fully Initialized", but <emphasis role="strong">client code</emphasis> may trigger proxy resolution as early as right after parsing, i.e. already in resource load state "Loaded".</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_validation">
-<title>Validation</title>
-<warning>
-<simpara>This chapter may be outdated.</simpara>
-</warning>
-<simpara>In this chapter the concept for the validation infrastructure of the N4JS IDE is described.</simpara>
-<simpara>Requirements:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>like in old IDE centralize issue codes and messages</simpara>
-</listitem>
-<listitem>
-<simpara>instead of the DLTK API, the Xtext Validation API should be used</simpara>
-</listitem>
-<listitem>
-<simpara>there should be an unified approach / call to produce validation messages (as in old IDE with the call of reportProblem)</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="sec:validation_overview" role="language-n4js">
-<title>Validation overview</title>
-<itemizedlist>
-<listitem>
-<simpara>in Xtext in most cases validation should triggered after all Xtext resources are linked (so everything is resolved), so most validations are defined in N4JSValidator and there in composed validators</simpara>
-</listitem>
-<listitem>
-<simpara>in Xtext there are resource diagnostics and validation diagnostics</simpara>
-<itemizedlist>
-<listitem>
-<simpara>resource diagnostics are produced for issues related to found syntax errors and linking errors</simpara>
-</listitem>
-<listitem>
-<simpara>validation diagnostics are produced for issues found during semantic validation (model invariants)</simpara>
-</listitem>
-<listitem>
-<simpara>Note, that you can only produce diagnostics only for the resource currenlty validated - e.g. it isn’t possible to create a marker for a duplicate issue in the other resource that contains the first element while producing the issue for the second - you have to create the diagnostic when validating the other resource</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>validation message sources</simpara>
-<itemizedlist>
-<listitem>
-<simpara>parser, e.g. ANTLR parser: messages are contained and produced internally by the parser but can be adapted by a customized SyntaxErrorMessageProvider (see link section below)</simpara>
-</listitem>
-<listitem>
-<simpara>lazy linking - N4JSLinker (extension of lazy linker): custom handling exceptions from value converters, that produces own issues as XtextLinkingDiagnostic (this is a resource diagnostic)</simpara>
-</listitem>
-<listitem>
-<simpara>lazy linking - ASTStructureValidator: traverses AST and produces custom DiagnosticMessage (triggered during N4JSLinker.doLinkModel), creates XtextLinkingDiagnostic (this is a resource diagnostic). The ASTStructureValidator checks for things like allowed occurence of continue, break, return as well as allowed labels</simpara>
-</listitem>
-<listitem>
-<simpara>linking - default: uses the ILinkingDiagnosticMessageProvider to create error messages for typical error cases (referenced not resolved, unique constraint violation, bounds contraints violation, etc.)</simpara>
-</listitem>
-<listitem>
-<simpara>linking - ErrorAwareLinkingService: In N4JS we have introduced a custom IEObjectDescription AbstractDescriptionWithError that holds issue code and error message and ErrorAwareLinkingService as extension of DefaultLinkingService to produce for every AbstractDescriptionWithError a XtextLinkingDiagnostic (this is a resource diagnostic) - the usual Xtext behavior would be to produce a linking error with linking disabled, with our customization linking still works but the error message/marker is produced as well. Currently there are these custom AbstractDescriptionWithError implementations, that are produced during scoping</simpara>
-<itemizedlist>
-<listitem>
-<simpara>AmbiguousImportDescription: indicate an ambiguous wildcard import</simpara>
-</listitem>
-<listitem>
-<simpara>PlainAccessOfAliasedImportDescription: indicate accessing type directly instead of using the alias it has been imported with</simpara>
-</listitem>
-<listitem>
-<simpara>InvisibleMemberDescription: indicate accessing a member, that is not visible to the caller due to access modifier restrictions</simpara>
-</listitem>
-<listitem>
-<simpara>InvisibleTypeOrVariableDescription: indicate accessing a type / variable or function, that is not visible to the caller due to access modifier restrictions</simpara>
-</listitem>
-<listitem>
-<simpara>WrongFieldAccessorDescription: setter/getter access used in wrong context</simpara>
-</listitem>
-<listitem>
-<simpara>WrongStaticAccessorDescription: static/non-static access used in wrong context</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>N4JSTypeSystem:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>error: cannot type given expression</simpara>
-</listitem>
-<listitem>
-<simpara>error: element is not a subtype of another type</simpara>
-</listitem>
-<listitem>
-<simpara>RuleFailedException is thrown in type system, then handled as result where out of the contained information the AbstractDeclarativeValidator API is used to create issues via calls to error(..) or warning(..) methods</simpara>
-</listitem>
-<listitem>
-<simpara>RuleFailedExceptionWithoutStacktrace - sub class of RuleFailedException</simpara>
-</listitem>
-<listitem>
-<simpara>N4JSTypeValidator.createError → delegates to AbstractDeclarativeValidator, or directly calls AbstractDeclarativeValidator.error</simpara>
-</listitem>
-<listitem>
-<simpara>XsemanticsValidatorErrorGenerator (currently not used)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>N4JSValidation: composed validators, declarative checks, i.e. using annotation @Check at methods, issues mostly created by using combination of message, context object, EFeature and index passed to AbstractDeclarativeValidator methods like error(..), warning(..)</simpara>
-<itemizedlist>
-<listitem>
-<simpara>N4JSClassValidator - checks related to classes, like duplicate member check</simpara>
-</listitem>
-<listitem>
-<simpara>N4JSFunctionValidator - checks for function expressions in expression statements and creates an error, but this validation is already done by the ASTStructureValidator</simpara>
-</listitem>
-<listitem>
-<simpara>N4JSImportValidator - checks invalid, duplicated and invalid imports</simpara>
-</listitem>
-<listitem>
-<simpara>N4JSInterfaceValidator - currently checks only for static members</simpara>
-</listitem>
-<listitem>
-<simpara>N4JSRoleValidator - currently checks only for static members</simpara>
-</listitem>
-<listitem>
-<simpara>N4JSStrictValidator - checks for function expressions in expression statements and creates an error, but this validation is already done by the ASTStructureValidator, thus this composite test is commented out</simpara>
-</listitem>
-<listitem>
-<simpara>N4JSTypeValidator - this is type system, see above</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Check types and check modes</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Check types are used in <literal>@Check</literal> annotation to influence, when a validation is triggered</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>FAST</literal> - Check is declared as fast</simpara>
-</listitem>
-<listitem>
-<simpara><literal>NORMAL</literal> - the common checks</simpara>
-</listitem>
-<listitem>
-<simpara><literal>EXPENSIVE</literal> - long running checks</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Check modes decide using check types when to run which types of checks</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>FAST_ONLY</literal> - used by Xtext editor to execute FAST checks on every key stroke and in embedded Xtext editors</simpara>
-</listitem>
-<listitem>
-<simpara><literal>NORMAL_ONLY</literal> - not used in Xtext framework itself</simpara>
-</listitem>
-<listitem>
-<simpara><literal>EXPENSIVE_ONLY</literal> - not used in Xtext framework itself</simpara>
-</listitem>
-<listitem>
-<simpara><literal>NORMAL_AND_FAST</literal> - used by Xtext editor to execute FAST and NORMAL checks on file save as well as on marker update for changed resources (delta calculated by Xtext builder)</simpara>
-</listitem>
-<listitem>
-<simpara>ALL - executes all types of checks when invoking explicitley the Validate action in the context menu of the Xtext editor</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>So by default check types and modes aren’t configurable at runtime</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Severity</simpara>
-<itemizedlist>
-<listitem>
-<simpara>types</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>ERROR</literal> - indicates a serious issue, that later will prevent things like builder, compiler and so on, to run</simpara>
-</listitem>
-<listitem>
-<simpara><literal>WARNING</literal> - indicates a possible semantic problem, where the user have to decide how to handle it. Issues with such severity won’t stop any post processing</simpara>
-</listitem>
-<listitem>
-<simpara><literal>INFO</literal> - only an information hint for the user. Note, it is not allowed to create a diagnostic with severity INFO.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>can be statically provided by calling the AbstractDeclarativeValidator methods error(..), warning(..), info(..) or directly pass the severity to a sub class of AbstractValidationDiagnostic (e.g. FeatureBasedDiagnostic, RangeBasedDiagnostic)</simpara>
-</listitem>
-<listitem>
-<simpara>can also determined dynamically at runtime with using the IssueSeveritiesProvider and a implementation of IPreferenceValuesProvider (e.g. the EclipsePreferencesProvider that uses the Eclipse preference store and preference page)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Issue codes</simpara>
-<itemizedlist>
-<listitem>
-<simpara>used to identify an issue elsewhere, e.g. when applying an quickfix for a validation issue but also for configuring validation handling (e.g. in a Eclipse preference page).</simpara>
-</listitem>
-<listitem>
-<simpara>We can use this issue code to also externalize the issue messages at a central place</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Issue data: String array to store additional data to be used in other places (e.g. hints for quickfixes)</simpara>
-</listitem>
-<listitem>
-<simpara>message: The message shown as text for the marker created at the resource in Eclipse and shown in the Xtext editor but also available by the methods getWarnings and getErrors at the XtextResource itself and so usable when logging messages to console in headless mode</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:validation_control_flow" role="language-n4js">
-<title>Validation control flow</title>
-<simpara><xref linkend="fig:cd_validation"/> gives an overview over the common control flow that triggers validation.</simpara>
-<figure xml:id="fig:cd_validation" role="center">
-<title>Validation control flow</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/10_validation/images/cd_validation.svg"/>
-</imageobject>
-<textobject><phrase>cd validation</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Validation is either triggered by dirty state handling (editing an Xtext document without saving starts a validation job) or by the automated build (invoked directly or started by resource changes in the project e.g. after saving a file).</simpara>
-<simpara>While in dirty state handling the current resource is already parsed and resolved the builder have to load the resource.</simpara>
-<simpara>All issues collected during load (i.e. during parsing, linking and scoping) the resource are added to the resource.</simpara>
-<simpara>In the automated build process there is step <literal>updateMarkers</literal> that triggers the validation.</simpara>
-<simpara>The <literal>SourceContainerAwareResourceValidator</literal> is a customization by us to handle only files that are contained in folders declared as source container by the package.json file.</simpara>
-<simpara>The <literal>CancelableDiagnostican</literal>, called by the resource validator, iterates over all elements contained in the resource. For each element the bound validator is called, in our case <literal>N4JSValidator</literal>, as it is registered as validator for the N4JS EPackage (in <literal>AbstractN4JSValidator</literal>).</simpara>
-<simpara>As this validator extends <literal>AbstractDeclarativeValidator</literal> in the first step all methods that are annotated with @Check and that have exactly one parameter are collected keyed by the type of their input parameter. The result of this collection process is cached. There is a defined order how the methods are collected:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>all local methods</simpara>
-</listitem>
-<listitem>
-<simpara>all methods recursively found in the super classes of the current class</simpara>
-</listitem>
-<listitem>
-<simpara>all methods found for the in the composed check annotation defined validators (by applying this algorithm as well)</simpara>
-</listitem>
-<listitem>
-<simpara>all methods recursively found in the composed checks in the super classes of the current class (by applying this algorithm as well)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The <literal>N4JSValidator</literal> filters all methods that uses the type of the currently traversed element from the before collected check methods and invokes them with the element from the resource.</simpara>
-<simpara>The Xsemantics type system validator is used as one of the composed validators in <literal>N4JSValidator</literal>. So although <literal>N4JSValidator</literal> extends <literal>N4JSTypeSystemValidator</literal>, <literal>N4JSTypeSystemValidator</literal> just re-uses the validation infrastructure but not its call hierarchy.</simpara>
-</section>
-<section xml:id="sec:validation_issue_ids" role="language-n4js">
-<title>Issue IDs and Messages</title>
-<simpara>For now the NLS validation message bundle resides in<?asciidoc-br?>
-<literal>/org.eclipse.n4js/src/org/eclipse/n4js/validation/messages.properties</literal><?asciidoc-br?>
-The entries in the messages.properties follows the pattern as described in <literal>NLSProcessor</literal>, the NLS class is <literal>IssueCodes</literal></simpara>
-<tip>
-<simpara>We use the same pattern for semver and json.</simpara>
-</tip>
-<itemizedlist>
-<listitem>
-<simpara>IDs shouldn’t be to long, as there might be a lot of markers and the issue codes are stored in memory</simpara>
-</listitem>
-<listitem>
-<simpara>the ID should encode where the issue has been created, therefore there should be common used prefixes like</simpara>
-<itemizedlist>
-<listitem>
-<simpara>PRS for parser (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>VCO for value converter</simpara>
-</listitem>
-<listitem>
-<simpara>AST for issues found during AST traversal</simpara>
-</listitem>
-<listitem>
-<simpara>LIN for issues found during scoping/linking (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>TYS for type system</simpara>
-</listitem>
-<listitem>
-<simpara>VAL for semantic validation (not used yet)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>besides the source also the domain of the issue should be encoded (the following list may reduced or extended over time, when it gets obvious which sorts of domain specific validations are required in which frequency)</simpara>
-<itemizedlist>
-<listitem>
-<simpara>CLF for issues common to all classifiers</simpara>
-</listitem>
-<listitem>
-<simpara>CLA for classes (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>ROL for roles</simpara>
-</listitem>
-<listitem>
-<simpara>FUN for function</simpara>
-</listitem>
-<listitem>
-<simpara>IMP for imports</simpara>
-</listitem>
-<listitem>
-<simpara>VAR for variables (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>MEM for classifier members in general</simpara>
-</listitem>
-<listitem>
-<simpara>OLI for object literals (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>ENU for enumerations (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>ARR for array literals (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>ANN for annotation related issues (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>EXP for expression related issues (assignment expression, binary expression, etc.) (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>STMT for statement related issues, such as if-else (conditional) , loops, switch etc.</simpara>
-</listitem>
-<listitem>
-<simpara>PRP for property access related issues (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>EXC for exception handling related issues (not used yet)</simpara>
-</listitem>
-<listitem>
-<simpara>LBL for labels related issues (not used yet)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>also technical validation aspects can be encoded</simpara>
-<itemizedlist>
-<listitem>
-<simpara>DUP for duplicate checks</simpara>
-</listitem>
-<listitem>
-<simpara>VIS for visibility checks (public, private, export, etc.)</simpara>
-</listitem>
-<listitem>
-<simpara>STR for issues related only applied in strict mode</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>examples</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>IMP_AMBIGUOUS</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>VIS_ILLEGAL_MEMBER_ACCESS</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>CLF_ABSTRACT_FINAL</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>AST_RESERVED_IDENTIFIER</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>VCO_HEXINT_CONVERT_EMPTY_STR</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>TYS_NO_SUBTYPE</literal></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:validation_usage_patterns" role="language-n4js">
-<title>Usage Pattern</title>
-<simpara>Due to the different places and circumstances a real unification of the API wasn’t possible yet (and wouldn’t have made sense), so there are these different usage patterns</simpara>
-<itemizedlist>
-<listitem>
-<simpara>in a custom error aware EObjectDescription like WrongFieldAccessorDescription you just return the issue code in getIssueCode and the message created using the issue code as well as the replacements for the wildcards in getMessage</simpara>
-</listitem>
-<listitem>
-<simpara>in a validator extending AbstractDeclarativeValidator you just call <literal>addIssue(message, context, EFeature, issueCode)</literal>. The message you have to create before by calling the corresponding <literal>getMessageFor[ISSUE_ID]</literal> method passing the required wildcard replacement</simpara>
-</listitem>
-<listitem>
-<simpara>in the ASTStructureValidator you have to call <literal>producer.addDiagnostic(new DiagnosticMessage(IssueCodes.messageFor[ISSUE_ID](wildcard1, wildcard2, ..), IssueCodes.getDefaultSeverity(IssueCodes.[ISSUE_ID]), IssueCodes.[ISSUE_ID]))</literal></simpara>
-</listitem>
-<listitem>
-<simpara>in the custom value converters you have to pass the information to an exception, so the call is: <literal>new N4JSValueConverterException(IssueCodes.getMessageFor[ISSUE_ID](wildcard1, wildcard2, ..), IssueCodes.[ISSUE_ID], node, null)</literal>. Beside this exception also N4JSValueConverterWithValueException is used in some places. In N4JSLinker then these exceptions are catched and a DiagnosticMessage is created out of the informations contained in these exceptions.</simpara>
-</listitem>
-<listitem>
-<simpara>As Xsemantics uses hard wired error or warning in its grammar you cannot adapt these places, but there are currently only three messages produced by Xsemantic (cannot type, not a sub type, null object passed to system). They are all handled in N4JSTypeValidator.createError where the message from Xsemantic is split up in its parts and then passed as wild card replacements to e.g. <literal>IssueCodes.getMessageForTYS_NO_SUBTYPE</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:validation_links">
-<title>Links</title>
-<itemizedlist>
-<listitem>
-<simpara><link xl:href="http://www.eclipse.org/Xtext/documentation.html#validation">Xtext Runtime Concepts: Validation</link></simpara>
-</listitem>
-<listitem>
-<simpara><link xl:href="http://blog.dietmar-stoll.de/2013/04/multiple-validators-in-xtext.html">Multiple validators in Xtext</link></simpara>
-</listitem>
-<listitem>
-<simpara>Customize error messages</simpara>
-<itemizedlist>
-<listitem>
-<simpara><link xl:href="http://zarnekow.blogspot.de/2010/06/customizing-error-messages-in-xtext-10.html">Customizing error messages in Xtext</link></simpara>
-</listitem>
-<listitem>
-<simpara><link xl:href="http://blog.dietmar-stoll.de/2012/07/custom-syntax-error-messages-with-quick.html">Custom syntax error messages with quickfix</link></simpara>
-</listitem>
-<listitem>
-<simpara><link xl:href="http://stackoverflow.com/questions/14526524/xtext-customizing-error-msg-by-unordered-groups">Xtext: customizing error messages by unordered groups</link></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-</chapter>
-<chapter xml:id="_references">
-<title>References</title>
-<warning>
-<simpara>This chapter maybe outdated.</simpara>
-</warning>
-<section xml:id="sec:usecases">
-<title>Use cases</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Compilation</simpara>
-</entry>
-<entry>
-<simpara>for deciding in incremental builder which resources requires a recompilation</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Editing</simpara>
-</entry>
-<entry>
-<simpara>Dirty state calculation: for deciding which resources needs to be reparsed as references have changed</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>UI</simpara>
-</entry>
-<entry>
-<simpara>Such as <keycap>Find references</keycap>, find all places in the workspaces that points to the selected element</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Tools</simpara>
-</entry>
-<entry>
-<simpara>requiring references, such as refactorings, e.g., rename refactoring: apply the renaming of the element also to all references to it (like find by references)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:calculation_algorithm" role="language-n4js">
-<title>Calculation algorithm</title>
-<section xml:id="sec:Xtext_default_implementation">
-<title>Xtext default implementation</title>
-<simpara>Using Reference Descriptions:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>default implementation contained in method <literal>createReferenceDescriptions</literal> of <literal>o.e.x.resource.impl.DefaultResourceDescriptionStrategy</literal></simpara>
-</listitem>
-<listitem>
-<simpara>iterates over all EReferences of the EClass of the current element</simpara>
-</listitem>
-<listitem>
-<simpara>navigates all references and resolves them (already done before in DefaultResourceDescription.computeReferenceDescriptions)</simpara>
-</listitem>
-<listitem>
-<simpara>create reference description objects for all these references</simpara>
-</listitem>
-</itemizedlist>
-<simpara>In case of N4JS and the types, reference descriptions are also created for references to types model elements (definedType) and for references from Types element to AST.</simpara>
-<simpara>We do not use this default implementation for two reasons:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>expensive</simpara>
-</listitem>
-<listitem>
-<simpara>Default implementation of reference descriptions only calculates the direct dependencies but not the transitive ones + the calculation of the URIs is very expensive.</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:N4_implementation">
-<title>N4JS implementation</title>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>the Xtext default implementation is disabled by let <literal>N4JSResourceDescription.computeReferenceDescriptions</literal> return an empty list. Also the bound <literal>N4JSDescriptionUtils</literal> returns an empty list for collectOutgoingReferences</simpara>
-</listitem>
-<listitem>
-<simpara>Calculating <emphasis>direct references</emphasis> are only done inside <literal>N4JSResourceDescription.getImportedNames</literal> (that uses newly introduced <literal>N4JSCrossReferenceComputer.computeCrossRefs</literal> for collecting all direct dependencies) - here only (parameterized) type refs, types and identifiable elements are collected</simpara>
-</listitem>
-<listitem>
-<simpara>collect all <emphasis>transitive dependencies</emphasis>, i.e. all super classes, consumed roles and implemented interfaces in the type hierarchy and add their resources as dependency (this is done in <literal>N4JSResourceDescription.getImportedNames</literal> (after calculating all direct dependencies with <literal>N4JSResourceDescriptionStrategy</literal>)</simpara>
-</listitem>
-<listitem>
-<simpara>bind <literal>N4JSReferenceQueryExecutor</literal> as a custom implementation to calculate the target URIs for an given target element and bind <literal>N4JSReferenceFinder</literal> as a custom implementation to calculate reference descriptions to be used by the default Xtext found references UI (use case UI)</simpara>
-</listitem>
-</orderedlist>
-<simpara><literal>ClusteringBuilderState.doUpdate</literal> calculates if a dependent resource has changed (in the context of calculating the <literal>DefaultResourceDescriptionDelta</literal> out of the old and new resource descriptions). Each resource description consists of <literal>EObjectDescriptions</literal>. The <literal>EObjectDescription</literal> for <literal>Script</literal> also contains the types model (<literal>TModule</literal>) for the resource. The references between resources are implemented via the type model. If it has changed (compared with the user data of the old <literal>EObjectDescription</literal>) then all other resource descriptions registered as been dependent on the resource (the qualified names of the resource descriptions are serialized as imported names within the resource description) will be notified that a reparse is needed.</simpara>
-<simpara>For <emphasis>dirty state</emphasis> the same behavior is achieved via the dirty state editor support using the resource set of the editor (instead the file system resources).</simpara>
-<simpara>As the primitive and built-in types are fixed they are ignored when calculating the dirty state. When calculating dependending resources and dirty state the reference of an AST element to its defining type is ignored as is the reference from the type to its AST element</simpara>
-<simpara><link linkend="fig:cd_classes">Classes</link> shows the different entry points (user actions) and classes involved in the process.</simpara>
-<informalfigure xml:id="fig:cd_classes" role="center">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_references/images/cd_classes.svg"/>
-</imageobject>
-<textobject><phrase>title-"Reference handling"</phrase></textobject>
-</mediaobject>
-</informalfigure>
-</section>
-</section>
-<section xml:id="sec:PerformanceOfDependencyCalculation" role="language-n4js">
-<title>Performance Of Dependency Calculation</title>
-<simpara>Concerning frequency and contexts it is clear, that triggering <literal>Find references</literal> and rename refactoring is not as frequent as editing (n4)js files that leads to dirty state (very often as happens when editing) and to trigger compilation (at file save, also often). Calculating if a resource is affected by a change (dirty state calculation) may not be too expensive. But running compilation for too many files (or the wrong set of files) due to incorrect dirty state calculation is expensive.</simpara>
-<simpara><literal>N4JSResourceDescription.getImportedNames</literal> is invoked on every edit of a file in the editor, so on every edit the complete content has to be retraversed for possible new references (expensive but not avoidable). For the types of all found references the super types have to recalculated. Traversing the type hierarchy shouldn’t be too expensive.</simpara>
-<simpara>Possible optimization could be:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>caching of traversing referenced types whose resources had not changed since last edit</simpara>
-</listitem>
-<listitem>
-<simpara>not traversing types that are imported but non of their features are used within the current resource</simpara>
-</listitem>
-</orderedlist>
-<simpara><emphasis>Those optimization should be done only if there are real performance issues are discovered.</emphasis></simpara>
-</section>
-<section xml:id="sec:kinds_of_references" role="language-n4js">
-<title>Kinds of references</title>
-<section xml:id="sec:Cross_References_to_be_ignored">
-<title>Cross References to be ignored</title>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Element</entry>
-<entry align="left" valign="top">Reference</entry>
-<entry align="left" valign="top">Explanation</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara>TypeDefiningElement</simpara></entry>
-<entry align="left" valign="top"><simpara>definedType: Type</simpara></entry>
-<entry align="left" valign="top"><simpara>always inner resource change (e.g., Functions, Classifier)</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>types::Type</simpara></entry>
-<entry align="left" valign="top"><simpara>astElement</simpara></entry>
-<entry align="left" valign="top"><simpara>as always inner resource change</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ImportDeclaration</simpara></entry>
-<entry align="left" valign="top"><simpara>importedModule: TModule</simpara></entry>
-<entry align="left" valign="top"><simpara>only affected if the resource name changes (and such a change cannot be performed dirty)</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ContinueStatement</simpara></entry>
-<entry align="left" valign="top"><simpara>label: LabelledStatement</simpara></entry>
-<entry align="left" valign="top"><simpara>always inner resource changes</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>BreakStatement</simpara></entry>
-<entry align="left" valign="top"><simpara>label: LabelledStatement</simpara></entry>
-<entry align="left" valign="top"><simpara>always inner resource changes</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>types::PrimitiveType</simpara></entry>
-<entry align="left" valign="top"><simpara>autocoercedObject: TClassifier</simpara></entry>
-<entry align="left" valign="top"><simpara>fixed (immutable) and internal</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Cross_References_to_be_handled" role="language-n4js">
-<title>Cross References to be handled</title>
-<simpara>Cross References</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>types::ParameterizedTypeRef → declaredType : Type</simpara>
-</listitem>
-<listitem>
-<simpara>* → N4GetterDeclaration: N4FieldDeclaration type, but references to getter can be done also done from outside</simpara>
-</listitem>
-<listitem>
-<simpara>* → N4SetterDeclaration: undef, references to setter can be done also done from outside</simpara>
-</listitem>
-<listitem>
-<simpara>types::PrototypeTypeRef → type : Type</simpara>
-</listitem>
-</orderedlist>
-<simpara>Contained <literal>ParameterizedTypeRef</literal> and <literal>TypeVariables</literal> (that internally references to <literal>Type</literal>):</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>references to declared super types of a type (Class, Role, Interface), i.e. superType, consumedRoles, implementedInterfaces</simpara>
-</listitem>
-<listitem>
-<simpara>TypeVariable → declaredUpperBounds</simpara>
-</listitem>
-<listitem>
-<simpara>References in type arguments:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Wildcards → upper and lower bounds, e.g. <literal>var List<? super A> l1;</literal></simpara>
-</listitem>
-<listitem>
-<simpara>direct type references, e.g. <literal>var List<A> l;</literal></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</orderedlist>
-<simpara>Cross References to IdentifiableElement (types):</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>IdentifierRef → id : IdentifiableElement</simpara>
-</listitem>
-<listitem>
-<simpara>NamedImportSpecifier → importedElement : IdentifiableElement</simpara>
-</listitem>
-<listitem>
-<simpara>ParameterizedPropertyAccessExpression → property : IdentifiableElement</simpara>
-</listitem>
-<listitem>
-<simpara>PropertyAccessExpression → property : IdentifiableElement</simpara>
-</listitem>
-</orderedlist>
-<simpara>Contained IdentifierRef (that internally references to IdentifiableElement):</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>ParameterizedCallExpression → target</simpara>
-</listitem>
-<listitem>
-<simpara>as PrimaryExpression in MemberExpression</simpara>
-</listitem>
-</orderedlist>
-</section>
-</section>
-<section xml:id="sec:transitive_dependencies">
-<title>Transitive dependencies</title>
-<simpara>Besides the direct dependencies we also need the transitive dependencies, as demonstrated in the following example.</simpara>
-<formalpara xml:id="ex:transdepex">
-<title>Transitive Dependency</title>
-<para>
-<programlisting language="java" linenumbering="unnumbered">export class A {
- public myMethod()
-}</programlisting>
-</para>
-</formalpara>
-<formalpara>
-<title>Transitive Dependency pt.2</title>
-<para>
-<programlisting language="java" linenumbering="unnumbered">export class B extends my/test/A {
-}</programlisting>
-</para>
-</formalpara>
-<formalpara>
-<title>Transitive Dependency pt.3</title>
-<para>
-<programlisting language="java" linenumbering="unnumbered">export class C extends my/test/B {
- myMethodC() {
- this.myMethod()
- }
-}</programlisting>
-</para>
-</formalpara>
-<simpara>If the name of <literal>myMethod</literal> in A changes, C should get dirty. This can get more complicated, if, e.g., a method in a consumed role is renamed, which then leads to binding references to super types.</simpara>
-<simpara>Therefore all direct and indirect super types are calculated (including super classes, consumed roles and implemented interfaces) for all found directly referenced types. The qualified names of their resources are added to the list of imported names. <footnote><simpara>One could think of an optimization to only register those types that are not just imported or declared, but whose features are really in use. E.g., in one file another type be imported (and even used as type of variable), but non of its member is used. So changes to these members wouldn’t affect the current resources. However this might miss certain cases. E.g., when a method in the super class is removed and now the method with same signature of a consumed role would be used. The method of the role has no been used before, yet must not be ignored. Thus, currently all super classes, roles and interfaces and referenced classes are added as dependency regardless if their members are called.</simpara></footnote></simpara>
-<simpara>Other transitive dependencies:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>call of member mixed by a consumed role</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>role is consumed by role consumed by this class</simpara>
-</listitem>
-<listitem>
-<simpara>role is consumed by class inherited by this class</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>call of member available by implemented interface</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>interface is implemented by role consumed by this class</simpara>
-</listitem>
-<listitem>
-<simpara>interface is implemented by class inherited by this class</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>call of member available by extended class</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>class is extended by class inherited by this class</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>chained method calls</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>method is of type that itself has members which are directly called, so the type is not directly imported or referenced by name in the caller but indirectly required</simpara>
-</listitem>
-<listitem>
-<simpara>method is of type that itself inherits members which are directly called, so the type (and its super types) is not directly imported or referenced by name in the caller but indirectly required</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-<informalexample>
-<simpara>Each type is defined in its own file.</simpara>
-<programlisting language="java" linenumbering="unnumbered">export class MyClassOne {
- myMethodOne() {
- var MyClassTwo instance;
- instance.getElement().myMethodThree()
- }
-}</programlisting>
-<programlisting language="java" linenumbering="unnumbered">export class MyClassTwo {
- MyClassThree getElement() {
- return new MyClassThree;
- }
-}</programlisting>
-<programlisting language="java" linenumbering="unnumbered">export class MyClassThree {
- void myMethodThree() {}
-}</programlisting>
-<simpara>If <literal>myMethodThree</literal> is renamed this should affect MyClassOne.</simpara>
-<simpara>Note that the method call in <literal>MyClassOne</literal> directly binds to the method in <literal>MyClassThree</literal>. However, the dependencies are only managed by means of types. So, from that perspective, the dependency between <literal>MyClassOne</literal> and <literal>MyClassThree</literal> is indirect.</simpara>
-<programlisting language="java" linenumbering="unnumbered">export class MyClassOne {
- void myMethodOne() {
- var MyClassTwo instance;
- instance.myMethodTwo().getElement().myMethodFour()
- }
-}</programlisting>
-<programlisting language="java" linenumbering="unnumbered">export class MyClassTwo {
- MyClassThree<MyClassFour> myMethodTwo() {
- return null;
- }
-}</programlisting>
-<programlisting language="java" linenumbering="unnumbered">export class MyClassThree<T extends MyClassFour> {
- T element;
-
- T getElement() {
- return this.element;
- }
-}</programlisting>
-<programlisting language="java" linenumbering="unnumbered">export class MyClassFour {
- void myMethodFour() {
- }
-}</programlisting>
-<simpara>If <literal>myMethodFour</literal> is renamed this should affect <literal>MyClassOne</literal>.</simpara>
-</informalexample>
-<simpara>More examples are found in the tests (cf. <literal>..ide.n4js.dirtystate.BuilderParticipantPluginTest</literal> and <literal>…​BuilderParticipantPluginUITest</literal>)</simpara>
-</section>
-<section xml:id="sec:find-references" role="language-n4js">
-<title>Find references</title>
-<simpara>Find references is perceived as a feature in Eclipse IDE, but its implementation can also be useful in a headless scenario, e.g. in the compiler to drop dead code.
-Therefore, as opposed to the Xtext default implementations, the code was refactored to split the parts that depend on the UI from the non-UI dependent logic (see <literal>org.eclipse.n4js.findReferences</literal> vs. <literal>org.eclipse.n4js.ui.search</literal>).</simpara>
-<section xml:id="_background">
-<title>Background</title>
-<simpara>Since no reference descriptions are stored in the index for N4JS resources, the cross references have to be found by other means.
-That is, the list of imported names is used as an indicator to find resources that have a potential dependency to the searched element.
-These resources have to be checked thoroughly.
-That is, their clear text representation is checked at a first step against the clear text representation of the found element before the resource is fully loaded and cross references are resolved.</simpara>
-<simpara>The decision to drop reference descriptions from the index was deliberate since they would only report bogus information in the context of inheritance, e.g. a method <literal>getA</literal> of type <literal>B</literal> my be overridden by <literal>getA</literal> in type <literal>C</literal>.
-Concrete bindings against <literal>C.getA</literal> should also be reported as references to <literal>B.getA</literal> since they identify the same public API of the type hiearchy around <literal>B</literal>.
-Therefore reference descriptions could not be used to find dependencies between source snippets.</simpara>
-</section>
-<section xml:id="_how-find-references-work">
-<title>How Find References Work</title>
-<simpara>Methods for finding references are provided Xtext’s interface <literal>IReferenceFinder</literal> and can be used both by the UI or headlessly.
-The N4JS implementation of this interface for the N4JS language is the class <literal>ConcreteSyntaxAwareReferenceFinder</literal>.
-One of the key methods defined by the <literal>IReferenceFinder</literal> is <literal>void findAllReferences(TargetURIs, IResourceAccess, IResourceDescriptions, Acceptor, IProgressMonitor)</literal> that finds all places in all resources of the index whereby those places cross-reference one of the URIs contained in <literal>TargetURIs</literal> .</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>TargetURIs</literal> contains the set of URIs to be searched. The caller of <literal>IReferenceFinder</literal> is responsible for collecting the <literal>Target URIs</literal> to be searched.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>IResourceAccess</literal> is used to search local references. This is needed because local references are usually not index.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>IResourceDescriptions</literal> is the indexed.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Acceptor</literal> is called when a reference is found.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>IProgressMonitor</literal> is used for showing progress bar (can be null).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>In the following, we will have a look at the workflow to find references when triggered in the UI.
-After understanding the UI case, the workflow of find references in the headless case should be self-explanatory.</simpara>
-<simpara><link linkend="fig:findreference_workflow">Find reference workflow</link> shows the workflow of find references when triggered in the UI.</simpara>
-<informalfigure xml:id="fig:findreference_workflow" role="center">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_references/images/findreference_workflow.svg"/>
-</imageobject>
-<textobject><phrase>title-"Find reference workflow"</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>The following example will be used for explanation.</simpara>
-<formalpara>
-<title>A.n4js</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">import {B} from "B";
-let b = new B(); // B here is an IdentifierRef referring to TClass B in B.n4js</programlisting>
-</para>
-</formalpara>
-<formalpara>
-<title>B.n4js</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">export public class B {}</programlisting>
-</para>
-</formalpara>
-<section xml:id="_step-1-convert-cursor-position-to-declared-element">
-<title>Step 1: Convert Cursor Position to Declared Element</title>
-<simpara>This step is represented by the purple color in <link linkend="fig:findreference_workflow">Find reference workflow</link> diagram.</simpara>
-<simpara>In the IDE, for the sake of convenience, we allow the user to find references of an arbitrary element at the current cursor.
-For instance, while the cursor is currently at <literal>IdentifierRef B</literal> in the <literal>NewExpression</literal> in <literal>A.n4js</literal>, the user may want to find all references to <literal>B</literal>.
-In those cases, we first need to find declaration element of <literal>IdentifierRef B</literal> which is <literal>TClass B</literal>. The Target URIs then contains a single URI to <literal>TClass B</literal>.
-In diagram <link linkend="fig:findreference_workflow">Find reference workflow</link>, the classe <literal>EObjectAtOffsetHelper</literal> can convert the current cursor position into a declared element.</simpara>
-</section>
-<section xml:id="_step-2-convert-declared-element-to-target-uris">
-<title>Step 2: Convert Declared Element to Target URIs</title>
-<simpara>This step is represented by the yellow color in <link linkend="fig:findreference_workflow">Find reference workflow</link> diagram.</simpara>
-<simpara>The Target URIs contains the URIs whose references are to be searched.
-The caller guarantees that <emphasis>Target URIs contain only URIs to declared elements, i.e. definitions</emphasis>.
-For example, if we want to find references for <literal>N4ClassDeclaration B</literal> in <literal>B.n4js</literal>, the target URIs contains a URI to the AST node <literal>N4ClassDeclaration B</literal> and a URI to the TModule node <literal>TClass B</literal>.
-Note that, in addition to the URI to the AST node <literal>N4ClassDeclaration B</literal>, the URI to the derived TModule node <literal>TClass B</literal> is also needed because <literal>N4ClassDeclaration</literal> can never be a target of a cross reference.
-In the diagram <link linkend="fig:findreference_workflow">Find reference workflow</link> , the classes depicted in yellow color are responsible for converting declared elements to <literal>Target URIs</literal> taking care of the derived <literal>TModule</literal> nodes.</simpara>
-</section>
-<section xml:id="_step-3-filter-potential-resources">
-<title>Step 3: Filter Potential Resources</title>
-<simpara>This step is represented by the green color in <link linkend="fig:findreference_workflow">Find reference workflow</link> diagram.</simpara>
-<simpara>The general algorithm for finding references is to traverse the AST of each resource in the index and check each AST node if it has a cross reference to one of the URI in the <literal>Target URIs</literal>.
-However, this is too expensive because potentially all resources in the index have to be loaded.
-We need some way to quickly decide for a resource description if the corresponding resource may potentially contain the references before actually loading it for a more thorough search.
-This is done using two pieces of information:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>typesOrModulesToFind</literal>: the set containing the fully qualified names of the <literal>type</literal> and <literal>module</literal> of the declaration to be searched. This set is calculated in the class <literal>TargetURIKey</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>imported names</literal>: the set exposed by <literal>ResourceDescription</literal> that contains the types needed by the underlying resource. The implementation for calculating imported names can be found in the class <literal>N4JSResourceDescription</literal>.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>In our example, supposed that we are finding references for <literal>class B</literal>. The <literal>typesOrModulesToFind</literal> contains fully qualified names to <literal>N4ClassDeclaration B</literal> and <literal>module B</literal>, i.e. <literal>B.B</literal> and <literal>B</literal>.
-The <literal>imported names</literal> of the resource description of <literal>A.n4js</literal> contains fully qualified names to <literal>module B</literal>, <literal>class B</literal>, i.e. <literal>B</literal> and <literal>B.B</literal>.
-Since the set of imported names of <literal>A.n4js</literal> contains elements in <literal>typesOrModulesToFind</literal>, this resource is searched thoroughly for references.</simpara>
-</section>
-<section xml:id="_step-4-search-references-in-resource">
-<title>Step 4: Search References in Resource</title>
-<simpara>If a resource is considered as a candidate for a more thorough search in Step 3, it is loaded.
-Its AST is traversed and at each AST node we check if there is a cross reference to one of the Target URIs (Step 1).
-If yes, the AST node is collected in the set of found references.
-See class <literal>ConcreteSyntaxAwareReferenceFinder</literal> for implementation details.</simpara>
-<simpara>The UI dependent logic may apply additional filters to drop references that are not relevant to the user, e.g. the reference from an AST element to its inferred type and vice versa (see <literal>N4JSReferenceQueryExecutor.isToBeIgnored(EReference)</literal>).</simpara>
-</section>
-<section xml:id="_limitations-and-possible-enhancements">
-<title>Limitations and Possible Enhancements</title>
-<simpara>Other noteworthy limitations and potential enhancements of the current implementations are:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Semantics: Only references that are available in the model as real references are reported. Even though <literal>getB()</literal> in <literal>myA.getB().getC()</literal> may return an instance of type <literal>B</literal>, there is no reference reported to B in that expression, though a reference to a member of B would be reported for <literal>getC</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Visibility constraints are not applied and thus do not reduce the search scope to allow the report of invalidly established references in a later validation.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_compilation">
-<title>Compilation</title>
-<warning>
-<simpara>This chapter may be outdated.</simpara>
-</warning>
-<section xml:id="chap:compilation" role="language-n4js">
-<title>Introduction</title>
-<simpara>Compilation is the process of transforming some source code written by means of a human readable text into a machine readable target file, i.e. bytecode or assembler. However, in the context of N4JS, the target output is not machine code but another high-level programming language. This kind of compiler transforming from one programming language to another is called <emphasis>transpiler</emphasis>, as a combination of <literal>transformation</literal> and <literal>compiler</literal>. The design of the transpiler takes this special setup into account.</simpara>
-<section xml:id="sec:general_design_rationals">
-<title>General design rationals</title>
-<section xml:id="sec:logging_and_error_reporting">
-<title>Logging and error reporting</title>
-<simpara>The generator always expects to get a valid model as an input. So all syntactic and semantic errors (not warnings) in the N4JS code as well as regarding the project configuration, e.g. in the package.json file, should be already discovered in the validation step. So any error marker on the resource will prevent the compiler to run.</simpara>
-<simpara>In case of other errors arising in the generator, the error handling is done as follows:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>either throw an <literal>GeneratorException</literal> or better call <literal>ExceptionHandler.handleError(message)</literal> (that then will throw this exception)</simpara>
-</listitem>
-<listitem>
-<simpara>beside the message also the file and the current line can be passed to <literal>GeneratorException</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>GeneratorException</literal> (as extending RuntimeException) will be handled by the generator caller</simpara>
-<itemizedlist>
-<listitem>
-<simpara>in UI: <literal>BuildInstruction</literal> will create an error log entry</simpara>
-</listitem>
-<listitem>
-<simpara>headless: lets the <literal>GeneratorException</literal> fail</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:progress_monitor">
-<title>Progress monitor</title>
-<simpara>The compiler works on a single file and we do not expect that to take much time. Processors working on many files, such as linkers (in the JavaScript context, that is minification and concatenation), are different components.</simpara>
-</section>
-</section>
-<section xml:id="sec:Xtext_Integration">
-<title>Xtext Integration</title>
-<section xml:id="sec:xtext_default_behaviour">
-<title>Xtext default behaviour</title>
-<simpara>The Xtext builder participant calculates the delta for every change in the project and triggers dirty state handling as well as code generation. By default the builder participant expects exactly one implementation bound to the IGenerator interface and thus only one output configuration provider belonging to this generator.</simpara>
-</section>
-<section xml:id="sec:n4js_requirements">
-<title>N4JS requirements</title>
-<simpara>In constrast to the default Xtext behaviour in the N4JS IDE allows</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the registration / discovery of multiple generators (including compilers and transpilers) but even no compiler at all, so that it is possible to ship the IDE also without any generators</simpara>
-</listitem>
-<listitem>
-<simpara>to configure these generators separately (output paths and so on) workspace globally but also project specific (currently it is only required to enable / disable a compiler)</simpara>
-</listitem>
-<listitem>
-<simpara>to enable / disable generators, but it is allowed to enable more than one compiler at one</simpara>
-</listitem>
-<listitem>
-<simpara>to start compilers headless, i.e. e.g in automated build / JUnit tests but with the possibility to configure them there as well</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:compiler_discovery_in_ui">
-<title>Compiler discovery in UI</title>
-<itemizedlist>
-<listitem>
-<simpara>There is a singleton <literal>ICompositeGenerator</literal>. The <literal>ICompositeGenerator</literal> instance itself doesn’t contain generator logic but knows subgenerators (that implement <literal>ISubGenerator</literal>) to which it delegates the input file (so instead of registering a new builder participant (that then would have to recalculate the delta) only the generator call is extracted)</simpara>
-</listitem>
-<listitem>
-<simpara>In the UI case, the actual execution of the registered generator is done in <literal>BuildInstruction</literal> where every N4JS resource contained in the delta calculated by the builder participant is an <literal>ICompositeGenerator</literal> implementation.</simpara>
-</listitem>
-<listitem>
-<simpara><xref linkend="fig:cd_GeneratorAndBuilderParticipant"/> summarizes the implementation of this compiler infrastructure in the UI case.</simpara>
-</listitem>
-</itemizedlist>
-<figure xml:id="fig:cd_GeneratorAndBuilderParticipant" role="center">
-<title>Builder (UI) and Generator (Core)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/cd_GeneratorAndBuilderParticipant.svg"/>
-</imageobject>
-<textobject><phrase>cd GeneratorAndBuilderParticipant</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:compiler_discovery_in_headless">
-<title>Compiler discovery in headless</title>
-<itemizedlist>
-<listitem>
-<simpara><literal>N4JSHeadlessStandaloneSetup</literal> is used to combine <literal>N4JSRuntimeModule</literal> and <literal>N4JSHeadlessGeneratorModule</literal> so there is <literal>PropertiesFileBasedValuesProvider</literal> is bind as implementation for <literal>IPreferenceValuesProvider</literal></simpara>
-</listitem>
-<listitem>
-<simpara>via <literal>N4JSHeadlessStandaloneSetup</literal> the injector is created which is used to create an instance of <literal>ICompositeGenerator</literal></simpara>
-</listitem>
-<listitem>
-<simpara>in the headless mode the subgenerators of are manually registered via an extension point in the class <literal>HeadlessExtensionRegistrationHelper</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:general_generator_implementation">
-<title>General generator implementation</title>
-<example>
-<title>Simple IGenerator</title>
-<simpara>The following snippet shows a minimal generator example.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">public class Generator implements IGenerator {
- @Override public void doGenerate(Resource resource, IFileSystemAccess fsa) {
- final String filename = computeTargetFileName(resource.getURI());
-
- Script script = IterableExtensions.<Script> head(
- Iterables.<Script> filter(resource.getContents(), Script.class));
-
- fsa.generateFile(filename, doCompileToString(script));
- }
-}</programlisting>
-<simpara>Generation is triggered for each Xtext resource. <literal>IFileSystemAccess</literal> is an abstraction of where to write the generated artefacts. This enables using the generator in the IDE (with a workspace) and headless (directly operating on files). In tests you can use <literal>InMemoryFileAccess</literal>, in standalone mode you should use <literal>JavaFileSystemAccess</literal> and in Eclipse mode <literal>EclipseFileSystemAccess2</literal></simpara>
-</example>
-</section>
-<section xml:id="sec:general_generator_activation">
-<title>General generator activation</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Programmatically</simpara>
-</entry>
-<entry>
-<simpara>Invoke the <literal>IComposedGenerator.doGenerate</literal> with a loaded N4JS resource and a configured <literal>IFileSystemAccess</literal> implementation.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Builder</simpara>
-</entry>
-<entry>
-<simpara>This is available by default when using the bound <literal>IGenerator</literal>, it runs on every change of your N4JS resource when automatic build is enabled in the workspace.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Context Menu</simpara>
-</entry>
-<entry>
-<simpara>see <link xl:href="christiandietrich.wordpress.com/2011/10/15/xtext-calling-the-generator-from-a-context-menu/">Christian Dietrich’s Blog 2011/10/15</link></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>MWE2 Workflow</simpara>
-</entry>
-<entry>
-<simpara>via <literal>org.eclipse.xtext.generator.GeneratorComponent</literal> that is configured with the standalone setup of the N4JS language. Such an MWE2 workflow also requires the <literal>org.eclipse.xtext.mwe.Reader</literal> component to first load the N4JS resources to transform in a model slot that is then consumed by the GeneratorComponent</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-</section>
-<section xml:id="sec:Overview_of_Input_Models">
-<title>Overview of the Input Models</title>
-<simpara>The input is a simple instance of <literal>Script</literal>, which is the root model element for all N4JS files. Actually, it is the root of the AST. For the AST elements, other elements stemming from other models are accessible as well. The following models may be important for the compiler:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>N4JS AST</simpara>
-</entry>
-<entry>
-<simpara>The abstract syntax tree is an EMF model, it is defined in a single Xcore file <literal>N4JS.xcore</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Parser or Node Model</simpara>
-</entry>
-<entry>
-<simpara>The parser tree, also called node model, is defined by Xtext. It contains offset information, holding whitespaces, line breaks, comments as well as other hidden tokens. It can be accessed via <literal>NodelModelUtils</literal>, that is a node can be retrieved for a given AST element and vice versa. There are three different kind of nodes: root, composite and leaf node.<?asciidoc-br?>
-<emphasis role="strong">As of Dec 2015, the transpiler does no longer make use of the parse tree!</emphasis></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Type Model</simpara>
-</entry>
-<entry>
-<simpara>The type model is an abstract view on the N4JS AST. It is defined in a single Xcore file <literal>Types.xcore</literal>. Not all AST elements are related to type model information. This is only true for subtypes of <literal>TypeDefiningElement</literal>, with references to <literal>Type</literal> or containing a <literal>TypeRef</literal>.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>N4 Project</simpara>
-</entry>
-<entry>
-<simpara>via <literal>OutputPathHelper</literal> located in <literal>org.eclipse.n4js.generator</literal> wraps the calculation of compiled file path.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Grammar Model</simpara>
-</entry>
-<entry>
-<simpara>Grammar Model created from <literal>N4JS.xtext</literal>, the rules can be access in the Java code via <literal>N4JSGrammarAccess</literal>. The grammar elements can be retrieved from the parser model vial <literal>node.getGrammarElement()</literal>. <literal>org.eclipse.xtext.GrammarUtil</literal> also contains some useful helper methods.<?asciidoc-br?>
-<emphasis role="strong">As of Dec 2015, the transpiler does no longer make use of the grammar model!</emphasis></simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-</section>
-<section xml:id="sec:Core_Generator" role="language-n4js">
-<title>Generators</title>
-<simpara>Generators are an abstraction above that of transpilers. N4JS transpilers are implemented as specific generators, but there might be other generators that are not transpilers (e.g. generator that produces HTML documentation from the jsdoc in the N4JS source files).</simpara>
-<section xml:id="sec:Compiler_Components">
-<title>Generator Components</title>
-<simpara><xref linkend="fig:comp_compilers"/> gives an overview over the compiler related components. Some of these components are described in detail in the following sections.
-As of Dec 2017, the generator architecture has been refactored and simplified.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>There is only a single <literal>ICompositeGenerator</literal> instance. Since the single instance should simply delegate to subgenerators, composite generators can no longer be registered via extension point.</simpara>
-</listitem>
-<listitem>
-<simpara>Most of generator related code is moved into <literal>org.eclipse.n4js</literal> bundle. This is needed because we need to bind <literal>ICompositeGenerator</literal> to a concrete implementation in the <literal>org.eclipse.n4js</literal> bundle and the extension point for <literal>ICompositeGenerator</literal> has been removed.</simpara>
-</listitem>
-<listitem>
-<simpara>An extension point <literal>org.eclipse.n4js.generator.subgenerator</literal> is introduced in the <literal>org.eclipse.n4js</literal> bundle. This makes it possible to register a new subgenerator via extension point.</simpara>
-</listitem>
-</itemizedlist>
-<figure xml:id="fig:comp_compilers" role="center">
-<title>Compiler Components</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/comp_compilers.svg"/>
-</imageobject>
-<textobject><phrase>comp compilers</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><xref linkend="fig:od_generatorInjection"/> shows how composite generator and subgenerators interact with other components both in the UI and in the headless case.</simpara>
-<figure xml:id="fig:od_generatorInjection" role="center">
-<title>Discovering generators and provide them with Guice bindings.</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/od_generatorInjection.svg"/>
-</imageobject>
-<textobject><phrase>od generatorInjection</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>As we can see in the diagram above. In the UI case, <literal>N4JSBuilderParticipant</literal> creates <literal>BuildInstruction</literal> which in turn delegates the generation logics to an instance of <literal>ICompositeGenerator</literal>. The <literal>ICompositeGenerator</literal> simply delegates the generation logics to subgenerators .</simpara>
-<simpara>In the headless mode, <literal>n4jscBase.doMain</literal> creates an instance of <literal>N4JSStandaloneSetup</literal> and obtains the injector from there. This injector is then used to create an instance of <literal>ICompositeGenerator</literal> in <literal>N4HeadlessCompiler</literal>.</simpara>
-</section>
-<section xml:id="sec:Generator_architecture">
-<title>Generator architecture</title>
-<simpara>The compiler has to create different compilation targets, e.g., for web applications running in a browser (Chrome), or for applications running on iOS using the JavaScriptCore framework <footnote><simpara><link xl:href="https://developer.apple.com/library/mac/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/_index.html">https://developer.apple.com/library/mac/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/_index.html</link></simpara></footnote>. Other scenarios may include code created for debugging purposes vs. optimized code, although this may be implementable via configuration switches as well.</simpara>
-<simpara><xref linkend="fig:cd_SubGenerators"/> shows the main generator classes, including two sub generators for EcmaScript code and EcmaScript on iOS.</simpara>
-<figure xml:id="fig:cd_SubGenerators" role="center">
-<title>Generator and sub-generators</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/cd_SubGenerators.svg"/>
-</imageobject>
-<textobject><phrase>cd SubGenerators</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:Unified_Compiler_Configuration">
-<title>Unified Compiler Configuration</title>
-<simpara>Since the compiler is to be used in both UI and headless (or CLI) mode, the configuration has to abstract from Eclipse <literal>IPreferenceStore</literal> concept or CLI utility classes. This is done with the combination of <literal>CompilerDescriptor</literal> and <literal>CompilerProperties</literal>, used by all <literal>ISubGenerator</literal> implementations (see <link linkend="fig:cd_SubGenerators">Fig. Sub Generators</link>).</simpara>
-<simpara>Each compiler provides</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a unique name (that have to match with the name of the output configuration)</simpara>
-</listitem>
-<listitem>
-<simpara>a default compiler descriptor that contains the preference values to be applied when nothing else been configured in the provided preference values</simpara>
-</listitem>
-</itemizedlist>
-<simpara>A <literal>CompilerDescriptor</literal> has</simpara>
-<itemizedlist>
-<listitem>
-<simpara>an identifier (this is the unique name of the compiler as mentioned before)</simpara>
-</listitem>
-<listitem>
-<simpara>a name (a readable name to used in Eclipse preference page)</simpara>
-</listitem>
-<listitem>
-<simpara>a description (not used yet, but maybe later also shown in the preference page)</simpara>
-</listitem>
-<listitem>
-<simpara>a flag, that indicates, if this generator should run by default</simpara>
-</listitem>
-<listitem>
-<simpara>the file extension to be used for the compiled file</simpara>
-</listitem>
-<listitem>
-<simpara>the <literal>OutputConfiguration</literal> object from Xtext that contains output related preferences like the output folder</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The <literal>CompilerProperties</literal> is an enumeration that makes it easier to iterate over the preferences and getting / setting the preference values in a generic way. So this enumeration contains all configurable properties as literals.</simpara>
-<simpara>The keys for preferences have to follow a fixed pattern as it also used internally by the builder participant when applying the configurations from the <literal>OutputConfiguration</literal>. So the key consists of</simpara>
-<itemizedlist>
-<listitem>
-<simpara>’outlet’</simpara>
-</listitem>
-<listitem>
-<simpara>unique name of the compiler = unique name of the output configuration</simpara>
-</listitem>
-<listitem>
-<simpara>the name of the property</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Example: outlet.es5.compiledFileExtension</simpara>
-<simpara><literal>N4JSPreferenceAccess</literal> encapsulates the access to the injected <literal>IPreferenceValuesProvider</literal>. This values provider is bound in UI to <literal>EclipsePreferencesProvider</literal> that creates an overlay over the default configuration and makes it so possible to have workspace global as well as project specific preferences and always as fall back the default values.</simpara>
-<simpara>In headless mode the <literal>PropertiesFileBasedValuesProvider</literal> is bound as implementation of <literal>IPreferenceValuesProvider</literal>. With this implementation it is possible to load the preferences from a provided properties file.</simpara>
-<simpara><literal>N4JSPreferenceAccess</literal> is used in <literal>AbstractSubGenerator</literal> which provided the most common used preferences as extra methods.</simpara>
-</section>
-</section>
-<section xml:id="sec:Transpilers" role="language-n4js">
-<title>Transpilers</title>
-<simpara>Transpilers are a special case of generators, used for transforming N4JS source code into some target code in some other, high-level programming language. In this section we describe the general transpiler infrastructure without considering any particular transpiler. Currently, there is only a single such concrete transpiler for ECMAScript target code, explained later in <xref linkend="sec:N4JS_to_EcmaScript_Transpiler"/>.</simpara>
-<simpara>All code of the general transpiler infrastructure is found in bundle <literal>org.eclipse.n4js.transpiler</literal>.</simpara>
-<section xml:id="sec:Phases">
-<title>Overview</title>
-<simpara><xref linkend="fig:ad_PipelineOverview"/> shows an overview of the steps during transpilation of a single resource:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>an initial conversion from the original AST to an <emphasis role="strong">intermediate model (IM)</emphasis>, called <emphasis role="strong">preparation step</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara>one or more <emphasis role="strong">transformation</emphasis> phases, each taking as input the IM and performing a number of in-place modification on it.</simpara>
-</listitem>
-<listitem>
-<simpara>a final <emphasis role="strong">pretty printing step</emphasis> that transform the final version of the IM into the textual output, i.e. the target code.</simpara>
-</listitem>
-</orderedlist>
-<figure xml:id="fig:ad_PipelineOverview" role="center">
-<title>Overview of the compilation pipeline</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/ad_PipelineOverview.svg"/>
-</imageobject>
-<textobject><phrase>ad PipelineOverview</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The IM is the most important data structure in the transpiler. It starts out as a 1-to-1 copy of the original AST and is then gradually transformed by the AST transformation steps into, ultimately, a representation of the output code. Only the IM undergoes updates, while the original AST remains unchanged. Nodes in the IM that are identical on N4JS source code and target code side can simply be left unchanged. Traceability links allow navigating back to an original AST node from a given IM node, but due to the gradual modification of the IM this might not be possible for all IM nodes (the tracer will return <literal>null</literal> in those cases.</simpara>
-<simpara>Ideally, each transformation executed during the transformation step should be self-contained and coupling should be reduced to a minimum. Of course, this is not possible in all cases, in practice. Therefore, a simple mechanism is provided for statically specifying dependencies between transformations by way of Java annotations (see Java class <literal>TransformationDependency</literal> for more details). The ECMAScript transpiler, for example, has 18 individual transformations (at time of writing).</simpara>
-</section>
-<section xml:id="relation-between-ast-and-im">
-<title>Relation between AST and IM</title>
-<simpara>The relation between the original AST and the IM is maintained by the tracer, see class <literal>Tracer</literal>, which is available via the transpiler state. The tracer allows to obtain a IM elements for a given original AST node and, conversely, original AST nodes for a given IM element (i.e. a 1:N association between original AST node and IM element).</simpara>
-<simpara>The main purpose of this tracing information is to compute source maps for the target code.</simpara>
-<simpara>At the beginning of the transformation step, there is a 1-to-1 correspondence between AST and IM, but over the course of the transformations this correspondence will become more and more blurred. Therefore, whenever using the tracer to get to the original AST from a given IM element , we have to consider the case that there is not original AST node defined for (because was created programmatically by an earlier transformation) OR that the original AST node is of a different kind than (because, maybe, an original N4JS class declaration was replaced by a function declaration by an earlier transformation).</simpara>
-<simpara>Whenever a transformation changes the IM, it is responsible to update the tracer, accordingly.</simpara>
-</section>
-<section xml:id="implementation-overview">
-<title>Implementation Overview</title>
-<simpara><link linkend="fig:transpilerClassDgr">Transpiler Class Diagram</link> shows a class diagram of the main constituents of the transpiler infrastructure.</simpara>
-<figure xml:id="fig:transpilerClassDgr" role="center">
-<title>Class diagram for the transpiler infrastructure.</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/TranspilerClassDgr.svg"/>
-</imageobject>
-<textobject><phrase>TranspilerClassDgr</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The <literal>AbstractTranspiler</literal> controls the overall workflow shown earlier in . Concrete subclasses of <literal>Transformation</literal> perform the actual transformations (the preparation and pretty-printing steps are not shown in the above class diagram). Concrete transformations are created via injection within concrete sub classes of <literal>AbstractTranspiler</literal> (see class <literal>EcmaScriptTranspiler</literal> for an example). All information required during transpilation is kept in a simple data class called <literal>TranspilerState</literal>; a single instance of this class is created during the preparation step and is passed along until transpilation of the resource to transpile is completed.</simpara>
-<simpara>Class <literal>Transformation</literal> has a super class <literal>TranspilerComponent</literal> that has two important responsibilities:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>it contains many utility methods that are easily accessible from within concrete transformations through inheritance.</simpara>
-</listitem>
-<listitem>
-<simpara>it obtains the transpiler state via injection (using the scoping feature of Google Guice, for more details see <literal>org.eclipse.n4js.utils.di.scopes.ScopeManager</literal> and <literal>TransformationScoped</literal>). This injection is done in super class <literal>TranspilerComponent</literal>, so when implementing a new transformation, the programmer does not have to deal with these details and can simply obtain the transpiler state via the inherited method <literal>TranspilerComponent#getState()</literal>.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Code shared across concrete transformations should be placed in sub classes of <literal>TransformationAssistant</literal>. Those assistants are similar to the helpers used elsewhere, but by sharing the <literal>TranspilerComponent</literal> super class they get all the utility methods provided by that class and they automatically get the transpiler state.</simpara>
-<simpara>For more implementation details see the code and javadoc; a good starting point for investigating the overall workflow are classes <literal>AbstractTranspiler</literal> and <literal>Transformation</literal>.</simpara>
-</section>
-<section xml:id="sec:Guidelines_for_Implementing_Transformations">
-<title>Guidelines for Implementing Transformations</title>
-<simpara>Some hints:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>if you need to create an entirely new transformation:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>create new sub class of <literal>Transformation</literal> (use Xtend).</simpara>
-</listitem>
-<listitem>
-<simpara>in the main class of the transpiler you are working with (probably <literal>EcmaScriptTranspiler</literal>), change method
-<literal>#computeTransformationsToBeExecuted()</literal> to return an instance of your new transformation. The instance should be created using a Guice provider (see <literal>EcmaScriptTranspiler</literal> for an example). Note that this method also defines the order of transformations!</simpara>
-</listitem>
-<listitem>
-<simpara>implement the <literal>#transform()</literal> method of your newly created transformation.</simpara>
-</listitem>
-<listitem>
-<simpara>consider adding pre and post conditions via methods <literal>#assertPreConditions()</literal> and <literal>#assertPostConditions()</literal> (throw an AssertionError if failed).</simpara>
-</listitem>
-<listitem>
-<simpara>consider declaring dependencies to other transformations using the annotations defined in class <literal>TransformationDependency</literal>.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>code shared across transformations should be placed in a new or existing sub class of <literal>TransformationAssistant</literal> and then this assistant should be injected into the transformations that require this code’s functionality.</simpara>
-</listitem>
-<listitem>
-<simpara>inside a transformation or transformation assistant:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>to modify the IM, use the utility methods inherited from <literal>TranspilerComponent</literal> (e.g. <literal>#replace()</literal>, <literal>#insertBefore()</literal>); try to avoid direct manipulation of the IM as far as possible (but sometimes it’s necessary).</simpara>
-</listitem>
-<listitem>
-<simpara>to create new IM elements, use the convenience methods in <literal>TranspilerBuilderBlocks</literal>; use static import.</simpara>
-</listitem>
-<listitem>
-<simpara>to create a new symbol table entry or to obtain an existing symbol table entry for a given original target or element in the IM, use the inherited utility methods <literal>TranspilerComponent#getSymbolTableEntry*()</literal>.<?asciidoc-br?>
-<emphasis role="strong">Never search or modify the symbol table directly!</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara>to access the transpiler state <footnote><simpara>but note that most utility methods obtain the transpiler state automatically; so, most of the time, you won’t need to obtain the state yourself.</simpara></footnote>, use inherited method <literal>TranspilerComponent#getState()</literal> (by convention, in Xtend you should just write <literal>state</literal> as if it were a field).</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>for local testing, activate additional consistency checks between transformations and assertion of pre/post conditions via these boolean flags:<?asciidoc-br?>
-<literal>AbstractTranspiler#DEBUG_PERFORM_VALIDATIONS</literal>,<?asciidoc-br?>
-<literal>AbstractTranspiler#DEBUG_PERFORM_ASSERTIONS</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>never add one of the following replaced EMF entities to the IM:<?asciidoc-br?>
-<literal>Script</literal>,<?asciidoc-br?>
-<literal>IdentifierRef</literal>,<?asciidoc-br?>
-<literal>ParameterizedTypeRef</literal>,<?asciidoc-br?>
-<literal>ParameterizedTypeRefStructural</literal>,<?asciidoc-br?>
-<literal>ParameterizedPropertyAccessExpression</literal>.<?asciidoc-br?>
-Instead, use the replacement entities from <literal>IM.xcore</literal> that have the <literal>_IM</literal> suffix (e.g. <literal>IdentifierRef_IM</literal>). If you always use <literal>TranspilerBuilderBlocks</literal> as described above, you won’t run into this issue.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="symbol-table-in-the-im">
-<title>Symbol Table in the IM</title>
-<simpara>During the preparation step, the IM is created as an exact copy of the original AST in most cases. However, to make sure the IM is self-contained and does not have any cross-references to the original AST or the original TModule and to simplify certain computations within the transformations, some AST entities are modified. For this purpose, there is a small EMF model called <literal>IM.xcore</literal>. It extends the AST model <literal>n4js.xcore</literal> and adds some elements.</simpara>
-<simpara>Most importantly, a symbol table is created and all references of the original AST pointing to an IdentifiableElement (either in the original AST or in the TModule) are rewired to a reference to an entry in the symbol table. Those entries are of type <literal>SymbolTableEntry</literal> and occur in three special forms (there is a dedicated sub class for each case). Detailed information is provided in the javadoc of <literal>SymbolTableEntry</literal> and its sub classes and is not repeated here to avoid duplication.</simpara>
-<simpara>The following entity replacements are done while creating the IM from the original AST and the entities without <literal>_IM</literal> must <emphasis role="strong">never</emphasis> appear in the IM:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>Script</literal> <literal>Script_IM</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>IdentifierRef</literal> <literal>IdentifierRef_IM</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>ParameterizedTypeRef</literal> <literal>ParameterizedTypeRef_IM</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>ParameterizedTypeRefStructural</literal> <literal>ParameterizedTypeRefStructural_IM</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>ParameterizedPropertyAccessExpression</literal> <literal>ParameterizedPropertyAccessExpression_IM</literal></simpara>
-</listitem>
-</itemizedlist>
-<simpara>For example, when having in the original AST an <literal>IdentifierRef</literal> pointing to identifiable element , then the IM will contain an <literal>IdentifierRef_IM</literal> pointing to a <literal>SymbolTableEntryOriginal</literal> with a property <literal>originalTarget</literal> pointing to .</simpara>
-<simpara>Figures <link linkend="fig:rewire_var">Rewire Var</link>, <link linkend="fig:rewire_class">Rewire Class</link>, and <link linkend="fig:rewire_import">Rewire Import</link> show a comparison between an original AST with its original TModule and the self-contained intermediate model for a number of concrete examples.</simpara>
-<example>
-<title>Intermediate Models for References to Variables</title>
-<simpara>Original AST + TModule</simpara>
-<figure xml:id="fig:rewire_var" role="center">
-<title>Intermediate Model for References to Variables</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/Rewire_var_pre.png"/>
-</imageobject>
-<textobject><phrase>Rewire var pre</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Intermediate model (IM)</simpara>
-<figure xml:id="fig:rewire_var-post" role="center">
-<title>Intermediate Model for References to Variables (post)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/Rewire_var_post.png"/>
-</imageobject>
-<textobject><phrase>Rewire var post</phrase></textobject>
-</mediaobject>
-</figure>
-</example>
-<example>
-<title>Intermediate Model for References to Classes</title>
-<simpara>original AST + TModule</simpara>
-<figure xml:id="fig:rewire_class" role="center">
-<title>Intermediate Model for References to Classes</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/Rewire_class_pre.png"/>
-</imageobject>
-<textobject><phrase>Rewire class pre</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Intermediate model (IM)</simpara>
-<figure xml:id="fig:rewire_class-post" role="center">
-<title>Intermediate Model for References to Classes (post)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/Rewire_class_post.png"/>
-</imageobject>
-<textobject><phrase>Rewire class post</phrase></textobject>
-</mediaobject>
-</figure>
-</example>
-<example>
-<title>Intermediate Model for References to Imported Classes</title>
-<simpara>Original AST + TModule</simpara>
-<figure xml:id="fig:rewire_import" role="center">
-<title>Intermediate Model for References to Imported Classes</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/Rewire_import_pre.png"/>
-</imageobject>
-<textobject><phrase>Rewire import pre</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Intermediate model (IM)</simpara>
-<figure xml:id="fig:rewire_import-post" role="center">
-<title>Intermediate Model for References to Imported Classes (post)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_compilation/images/Rewire_import_post.png"/>
-</imageobject>
-<textobject><phrase>Rewire import post</phrase></textobject>
-</mediaobject>
-</figure>
-</example>
-</section>
-</section>
-<section xml:id="sec:N4JS_to_EcmaScript_Transpiler" role="language-n4js">
-<title>N4JS-to-EcmaScript Transpiler</title>
-<section xml:id="sec:Overview_of_Transformations">
-<title>Overview of Transformations</title>
-<simpara>The following overview will soon be outdated. Therefore:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>to find out which transformations are actually being executed and in what precise order, it is best to directly look into method:<?asciidoc-br?>
-<literal>EcmaScriptTranspiler#computeTransformationsToBeExecuted()</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>to learn about dependencies between transformations, check the annotations of the transformation class to see if one of the dependency annotations defined in <literal>TransformationDependency</literal> are given there (though probably not all dependencies will be specified in that form).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The following table lists all transformation by class name in the order they are executed by the <literal>EcmaScriptTranspiler</literal>.</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="50*"/>
-<colspec colname="col_2" colwidth="50*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara>StaticPolyfillTransformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>MemberPatchingTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>see <link linkend="sec:Transpiling_members">Transpiling Members</link></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ApiImplStubGenerationTransformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>DestructuringTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>turn destructuring patterns into ES5 code</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>SuperLiteralTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>super call + super access</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ExpressionTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>casts, <literal>instanceof</literal>, <literal>@Promisify</literal>, …​</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>DependencyInjectionTransformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ClassDeclarationTransformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>InterfaceDeclarationTransformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>EnumDeclarationTransformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>FunctionDeclarationTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>turn declared function into variable declaration + function expression</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ArrowFunction_Part1_Transformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>BlockTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>local arguments variable, <literal>await</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>FormalParameterTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>variadic arguments</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ArrowFunction_Part2_Transformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>TrimTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>remove TypeRefs and TypeVariables</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>SanitizeImportsTransformation</simpara></entry>
-<entry align="left" valign="top"><simpara>remove unused imports + add missing imports</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>ModuleWrappingTransformation</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>The main complexity lies in the three transformations for N4JS type declarations (classes, interfaces, enums) and the related three transformations for member handling at the beginning (static polyfills, member patching, API/Impl stub generation) and the module wrapping. Up to the double horizontal line, the IM is still rather close to N4JS (e.g. still contains <literal>N4ClassDeclaration</literal>s with <literal>N4MemberDeclaration</literal>s), but after that it rapidly departs from the structure of the original AST (e.g. class declarations are broken up into a function declaration and a $<literal>makeClass</literal> call, field accessors and methods become function expressions in the properties of an object literal, fields are handled differently).</simpara>
-</section>
-<section xml:id="sec:Transpiling_members">
-<title>Transpiling members</title>
-<simpara>When processing the members of a container type, in the standard case, the transpiler simply has to generate target code for each owned member. For inherited members no output code has to be generated, because the ordinary semantics of the Javascript prototype chain is used in the generated code.</simpara>
-<simpara>There are, however, special cases when output code has to be generated for a non-owned or non-existant member of a container type:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>partial shadowing caused by lone field accessors, [sec:Transpiling_members__Partial_shadowing_of_getter_setter_pairs]<?asciidoc-br?>
-( <emphasis role="strong">delegation</emphasis>)</simpara>
-</listitem>
-<listitem>
-<simpara>consumption of members of an interface within an implementing class, [sec:Transpiling_members__Consuming_or_inheriting_members_of_an_interface]<?asciidoc-br?>
-( <emphasis role="strong">delegation</emphasis>, for data fields: <emphasis role="strong">copying</emphasis>)</simpara>
-</listitem>
-<listitem>
-<simpara>inheritance of members of an interface within an extending interface, [sec:Transpiling_members__Consuming_or_inheriting_members_of_an_interface]<?asciidoc-br?>
-( <emphasis role="strong">delegation</emphasis>, for data fields: <emphasis role="strong">copying</emphasis>)</simpara>
-</listitem>
-<listitem>
-<simpara>mixing in members into a container type via static polyfill, [sec:Transpiling_members__Static_polyfill]<?asciidoc-br?>
-( <emphasis role="strong">copying</emphasis>)</simpara>
-</listitem>
-<listitem>
-<simpara>adding an API / implementation stub, [sec:Transpiling_members__API_implementation_stubs]<?asciidoc-br?>
-( <emphasis role="strong">creation</emphasis>)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The above overview also states what technique is used in each special case of member handling: <emphasis role="strong">delegation</emphasis>, <emphasis role="strong">copying</emphasis> or <emphasis role="strong">creation</emphasis>. Delegation is the most tricky one and means that not a new function is generated in the output code for the special member, but the existing member function of an existing member is obtained from somewhere in the prototype chain and used directly as the member function of the special member. <emphasis role="strong">Copying</emphasis> means that an existing member is copied to another location where the special handling is required as if it were defined in that place. Lastly, <emphasis role="strong">creation</emphasis> means that an entirely new member is created for which no existing member serves as a template and this member gets a body with some <literal>default</literal> behavior. These three techniques of special member handling are explained in more detail in <xref linkend="sec:Transpiling_members__Delegating_members"/>.</simpara>
-<section xml:id="sec:Transpiling_members__Delegating_members">
-<title>Techniques for special member handling</title>
-<simpara>If output code has to be generated for a non-owned member of a classifier we distinguish the following two cases:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>either some other member owned by classifier serves as a template for ,</simpara>
-</listitem>
-<listitem>
-<simpara>or no such template exists.</simpara>
-</listitem>
-</orderedlist>
-<simpara>In the first case, we can either <emphasis role="strong">copy</emphasis> in the sense that we will generate output code for within the output code for as if had been defined in . Or we can use <emphasis role="strong">delegation</emphasis>, i.e. generate output code for that reuses the existing member function of in . In case no template exists, we always have to <emphasis role="strong">create</emphasis> from scratch, i.e. generate output code as if had been defined with some behavior pre-defined by the N4JS language (this applies only to API / implementation stubs where this pre-defined behaviour is to throw an <literal>unimplemented member</literal> error).</simpara>
-<simpara>Creation and copying is straightforward; for more details on member delegation see class <literal>DelegationAssistant</literal> and entity <literal>DelegatingMember</literal> in <literal>IM.xcore</literal>. The basic approach is to allow one transformation to create a <literal>DelegatingMember</literal> and insert it into the IM and let the transformations for class and interface declarations turn this member into low-level Javascript constructs that perform the actual delegation.</simpara>
-</section>
-<section xml:id="sec:Transpiling_members__Partial_shadowing_of_getter_setter_pairs">
-<title>Partial shadowing</title>
-<simpara>In Javascript, if an object has a setter of name , then a read access <literal>obj.prop</literal> will return undefined, even if the prototype of has a getter or field of name . Conversely, if has a getter , then a write access <literal>obj.prop = 42</literal> will produce a runtime error, even if the prototype of has a setter or field .</simpara>
-<screen>var proto = {
- get prop1() { return "this won't show up" },
- set prop2(value) { console.log("this won't be reached") }
-}
-var obj = {
- set prop1(value) {},
- get prop2() {}
-}
-obj.__proto__ = proto;
-
-console.log(typeof obj.prop1); // will print "undefined"
-obj.prop2 = 42; // error: "setting a property that has only a getter"</screen>
-<simpara>Note, in plain N4JS a validation enforces a redefinition of accessors or overriding of a field always by getter/setter pairs. However, in special situations of incomplete API implementations stubs for missing accessors are created in order to provide meaningful test-reporting. This leads to situations where on the implementation side a single getter or or a single setter is defined in a subclass - unaware of possibly injected stubs in superclasses. The aforementioned validation can not enforce the user to author an accessor pair. To keep a meaningful test-response the transpiler treats this situation as follows:</simpara>
-</section>
-<section xml:id="sec:Transpiling_members__Consuming_or_inheriting_members_of_an_interface">
-<title>Consuming or inheriting members of an interface</title>
-<simpara>When an N4JS class consumes the member of an interface implemented by , then this cannot be handled by the native prototype chain mechanism of Javascript. Instead, the transpiler has to generate a member of corresponding type that delegates to the consumed member. In case of data fields, such a delegation is not possible and thus the transpiler generates output code for the consumed data field as if the field had been defined in .</simpara>
-<simpara>Of particular importance in this context is the diamond problem when consuming members from an interface. For example, if interface defined method with a default implementation, interface extends and overrides with a different implementation, class implements and class extending implements , then will not consume because it has already inherited from its super class (which in turn has consumed it from ). So, in the default implementation of given in will be active, not that given in .</simpara>
-</section>
-<section xml:id="sec:Transpiling_members__Static_polyfill">
-<title>Static polyfill</title>
-<simpara>See class <literal>StaticPolyfillTransformation</literal> for details.</simpara>
-</section>
-<section xml:id="sec:Transpiling_members__API_implementation_stubs">
-<title>API / implementation stubs</title>
-<simpara>See <link linkend="sec:Support_for_incomplete_API_implementation_testing_in_the_N4JS_to_EcmaScript_5_Transpiler">Support for incomplete API implementation testing</link>.</simpara>
-</section>
-</section>
-<section xml:id="sec:Support_for_incomplete_API_implementation_testing_in_the_N4JS_to_EcmaScript_5_Transpiler">
-<title>Support for incomplete API implementation testing</title>
-<simpara>As part of the introduction of API projects with executable test cases the need to verify the state of implementations came into focus. No formal dependency is allowed between an API project and its dedicated implementation projects, hence an inconsistency can not directly be detected. However at runtime (c.f. <link linkend="_execution">Execution</link>) the API is always replaced by an appropriate implementation.</simpara>
-<simpara>In cases where such an implementation is incomplete this would result in failures due to missing concepts, e.g. calls to methods that are not in place or usage of fields which are not defined. In order to support the author of an implementation the IDE provides a mean to compare the current state of implementation to the developer in a tabular way (c.f. [<link linkend="N4JSSpec">N4JSSpec</link>]).</simpara>
-<simpara>The key idea for automated test-support is to incorporate those comparison-results into the transpiled output in way, that a test-framework can easily distinguish wrong implementations from incomplete implementations. Of course this is not always possible, but the majority of cases can be handled.</simpara>
-<simpara>As there is only one transpilation mode the resulting modifications are always part of the generated code.</simpara>
-<simpara>In order to distinguish the different project-types we distinguish between different project types:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>an API-project (API)</simpara>
-</listitem>
-<listitem>
-<simpara>an API-implementation project (Impl)</simpara>
-</listitem>
-<listitem>
-<simpara>a client project (Client)</simpara>
-</listitem>
-<listitem>
-<simpara>a test project (Test)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The API-project defines the requirements to it’s implementors in form of definition-files (n4jsd). The API is defined together with an test-project which validates the implementation. Client code is written with a formal dependency to the API and uses the elements declared therein. In that sense an API-testing project is just a normal client project with a test-nature.</simpara>
-<simpara>Additional code to support API implementation testing is only inserted into the Impl-projects. API, Client and Test are not affected.</simpara>
-<simpara>One major goal in transpiling Impl projects is to provide the ability to load all modules used in Client/Test projects in non-disruptive way. Even if the implementation is missing elements the runtime should still be able to successfully load the module. Errors should only be signalled when the client code actually uses the missing concepts.</simpara>
-<section xml:id="sec:Modifications_in_Impl_projects">
-<title>Modifications in Impl projects</title>
-<simpara>The generator is module driven. In case of missing modules nothing will be done but the runtime will detect this and act accordingly.</simpara>
-<simpara>In general only missing elements will be inserted:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Missing class - a stub will be generated</simpara>
-</listitem>
-<listitem>
-<simpara>Missing function - a stub will be generated</simpara>
-</listitem>
-<listitem>
-<simpara>Missing enumeration - a stub will be generated</simpara>
-</listitem>
-<listitem>
-<simpara>Missing interface - a stub will be generated</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Missing members of classes are inserted as stubs. Missing fields will be replaced by getter/setter-pairs throwing an error upon read and write access.</simpara>
-<simpara>A more sophisticated approach needs to be taken for interfaces with default implementations (marked with @ProvidesDefaultImplementation or @ProvidesInitializer).</simpara>
-<simpara>Currently missing field initialisers in interfaces are not detected for two reasons: Field-initialising is carried out on loading. Throwing an error in the initialiser will prevent the module from being loaded. Installing a getter/setter pair on the Impl-interface is not an option since the inheritance chain used in client project has no knowledge about this and therefore these accessors cannot be reached from client code.</simpara>
-<simpara>Missing default implementations will be inserted as stubs. For normal class compilation the inheritance chain needs to be scanned. In case of an missing default implementation in an implemented interface a forwarding call to the stub needs to be inserted on the class.</simpara>
-</section>
-<section xml:id="sec:Implementation_of_stub_generation">
-<title>Implementation of stub-generation</title>
-<simpara>The implementation is mainly organised in <literal>ApiImplStubGenerationTransformation</literal>, which makes use of <literal>MissingApiMembersForTranspiler</literal> and <literal>ScriptApiTracker</literal>.</simpara>
-<simpara>When a Module is transpiled the type of the project is checked. Only if the project is an implementation project the comparison between the current module and it’s API module is computed and attached as an Adapter to the <literal>Script</literal> during the life-cycle of the <literal>ScriptTranspilerPolicy</literal>. The <literal>ProjectComparisonAdapter</literal> serves as a shared information pool among the different transpiler-policies and caches different compare-results. After transpilation of the script the adapter will be removed.</simpara>
-<simpara>In order to reuse all existing code as far as possible, missing elements are modelled as subclasses of the requested element but with no AST-information. These subclasses are member-classes of the <literal>ScriptApiTracker</literal> class. All class-names are prefixed with <literal>VirtualApi</literal> and hold a reference to the type-information computed by the module-comparison.</simpara>
-<simpara>It is important to not access the AST-elements of type-information obtained from the project-comparison, since this would trigger the AST-loading and invalidate (proxifying) existing <literal>EObjects</literal>.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="sec:n4jsc_Headless_Compiler_Interface" role="language-n4js">
-<title>n4jsc Headless Compiler Interface</title>
-<simpara>The headless compiler interface consists of a runnable class capable of reading command line options packaged together with all required dependencies into one executable <literal>.jar</literal> archive.</simpara>
-<simpara>The sources of the command line interface are located in in the <literal>tools/</literal> subfolder of the main git repository. They comprise of the package <literal>org.eclipse.n4js.hlc</literal> and corresponding test package <literal>org.eclipse.n4js.hlc.tests</literal>. (c.f. <link linkend="sec:tools">Tools</link>).</simpara>
-<simpara>A description of how to use the headless compiler can be found in the N4IDE document.</simpara>
-<section xml:id="sec:building_the_headless_compiler">
-<title>building the headless compiler</title>
-<simpara>The maven-modules related to the headless compiler build are organised in the <literal>tools</literal> folder in the project-root. In order to build the headless compiler as part of the common build-chain, the maven-profile <literal>buildTools</literal> needs to be activated (off by default), e.g. <literal>mvn -PbuildTools</literal> .</simpara>
-<simpara>To build the headless compiler separately, the project-pom can be set to <literal>tools/pom.xml</literal>, however then the tycho-generated artefacts must be accessible by this build. This can be achieved in three different ways:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>the build takes place on a workspace formerly building the n4js-project without cleaning it (interesting for local experiments),</simpara>
-</listitem>
-<listitem>
-<simpara>a former n4js-build installed the artefacts into the currently configured local-.m2-repository of maven or</simpara>
-</listitem>
-<listitem>
-<simpara>a former n4js-build deployed the artefacts to the configured nexus-server.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Note however, on our build-server option a) is not feasible, option b) requires you to setup a build-chain and ensuring the same build-node to be building on
-and c) is difficult up to nearly impossible without a proper versioning-scheme.</simpara>
-<simpara>Parameters for the headless-compiler-build are defined in the parent-pom located at <literal>releng/org.eclipse.n4js.parent/pom.xml</literal> with properties prefixed by <literal>hlc.</literal>.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_execution">
-<title>Execution</title>
-<warning>
-<simpara>This chapter may be outdated.</simpara>
-</warning>
-<simpara>There are many different use cases for executing N4JS code:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>running project locally</simpara>
-</listitem>
-<listitem>
-<simpara>running tests in CI</simpara>
-</listitem>
-<listitem>
-<simpara>running application in the client</simpara>
-</listitem>
-<listitem>
-<simpara>running processor on the server</simpara>
-</listitem>
-</itemizedlist>
-<simpara>All those use cases may differ in their details, but can be divided into general phases:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>execution environment preparation</simpara>
-</listitem>
-<listitem>
-<simpara>bootstrapping</simpara>
-</listitem>
-<listitem>
-<simpara>call to given n4js entry point</simpara>
-</listitem>
-<listitem>
-<simpara>shutdown (optional)</simpara>
-</listitem>
-</orderedlist>
-<simpara>When N4JS execution is triggered, proper <emphasis>Runner</emphasis> (see <link linkend="sec:Runners-introduction">Runners</link>) is selected. In some cases it is done automatically, in others user needs to make a choice. Runner is responsible for perform all required preparations, according to <link linkend="sec:N4JS_Project_Execution_And_Linking_Model">N4JS Project Execution And Linking Model</link>. Then JS execution environment (e.g. NodeJS, IOJS, Chrome, JavaScriptCore) performs bootstrapping according to <xref linkend="sec:N4JS_Execution_And_Linking_File"/>. As last step of bootstrap phase defend n4js entry point will be called which starts proper n4js execution phase. In some cases there may be shutdown phase, but that is highly dependent on use case and proceeding execution phases.</simpara>
-<section xml:id="sec:N4JS_Project_Execution_And_Linking_Model" role="language-n4js">
-<title>N4JS Project Execution And Linking Model</title>
-<simpara>N4JS project is compiled to JavaScript language, that in turn can be executed in some JS execution environment, Those environments (e.g. NodeJS, IOJS, Chrome, JavaScriptCore) will differ between each other in terms of JS APIs they expose and way JS code has to be provided to them, or the way it is triggered. We introduced systematic way of describing those features in terms of N4JS projects (see Components and Projects <link linkend="sec:N4_Components_and_IDE_Support">Components and IDE Support</link>). N4JS project will be of different <emphasis>PojectType</emphasis> that determines project purpose (see Package.json section <xref linkend="sec:Package_json"/>. When we want to execute some N4JS project, we can divide its dependency graph into 4 general areas</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>User Space, e.g. user code</simpara>
-</listitem>
-<listitem>
-<simpara>System Space, e.g N4 Platform APIs</simpara>
-</listitem>
-<listitem>
-<simpara>Runtime Space, e.g. EcmaScript APIs</simpara>
-</listitem>
-<listitem>
-<simpara>Environment Space, e.g. execution environment APIs</simpara>
-</listitem>
-</orderedlist>
-<simpara>Example of that kind of graph can bee seen on <xref linkend="fig:od_sampleProjectDependencyGraph"/></simpara>
-<figure xml:id="fig:od_sampleProjectDependencyGraph" role="center">
-<title>Sample Project Dependency Graph</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/14_execution/images/od_sampleProjectDependencyGraph.svg"/>
-</imageobject>
-<textobject><phrase>od sampleProjectDependencyGraph</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>All dependencies are compile time dependency (as they are checked by the compiler), but <emphasis>tend</emphasis> to weaken, the lower in the dependency graph we are. <emphasis>User Space</emphasis> objects will have strong load time and run time dependency to each other and to the <emphasis>System Space</emphasis>. <emphasis>System Space</emphasis> have strong load time and run time dependency to each other and, only runtime dependency to <emphasis>Runtime Space</emphasis>. <emphasis>Runtime Space</emphasis> objects should not have any load time dependencies between each other. In some cases they may have weak runtime dependency to each other. In many cases those components are just api definitions that describe execution environment native apis, but may contain polyfills code. <emphasis>Environment Space</emphasis> has no dependency to other components, except the fact different <emphasis>RuntimeEnvironemnt</emphasis>s can extend each other (see <xref linkend="sec:N4_Components_and_IDE_Support"/>).</simpara>
-<simpara>Runner must configure JS execution environment in the way that all above areas of the dependency graph must be either</simpara>
-<itemizedlist>
-<listitem>
-<simpara>provided by execution environment itself (runtime libraries APIs - <emphasis>n4jsd</emphasis> files)</simpara>
-</listitem>
-<listitem>
-<simpara>loaded by defined runtime environment (self initialisation code)</simpara>
-</listitem>
-<listitem>
-<simpara>available to load by environment explicitly (runtime libraries polyfills, system libraries)</simpara>
-</listitem>
-<listitem>
-<simpara>available to load by other implicitly (system libraries, user libraries and projects)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Testers, the same way as runners, must be able to execute n4js code. Main difference is that dependency graph for test case will be usually slightly bigger (dependencies to test libraries), and code that has to be triggered shifts a bit from given project to test library used in test code of tested project. Extending previously used example with test elements is shown in figure <xref linkend="fig:od_sampleTestProjectDependencyGraph2"/>.</simpara>
-<figure xml:id="fig:od_sampleTestProjectDependencyGraph2" role="center">
-<title>Sample Test Project Dependency Graph</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/14_execution/images/od_sampleTestProjectDependencyGraph.svg"/>
-</imageobject>
-<textobject><phrase>od sampleTestProjectDependencyGraph</phrase></textobject>
-</mediaobject>
-</figure>
-<figure xml:id="fig:runners-testers" role="center">
-<title>Runners and Testers</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/14_execution/images/runners-testers.svg"/>
-</imageobject>
-<textobject><phrase>runners testers</phrase></textobject>
-</mediaobject>
-</figure>
-<section xml:id="subsec:N4JS_Execution_With_NodeJS" role="language-n4js">
-<title>N4JS Execution With NodeJS</title>
-<simpara>This example shows in-depth details of N4JS code execution with NodeJS runner.</simpara>
-<simpara>In the workspace we have <literal>Client</literal> with <literal>foo.n4js</literal> that imports <literal>bar.n4js</literal> from <literal>UserLib</literal> that is also in the workspace.
-Those N4JS files use some ES5 APIs , e.g. <literal>Math.random()</literal> and <literal>setTimeout()</literal>. Those APIs are <literal>Global</literal> so there is
-no impicit import, still they make user projects depend on runtime library <literal>n4js-runtime-es2015</literal>.
-Assuming user selects <literal>foo.n4js</literal> file for execution, the NodeRunner in the IDE will:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>create working directory in temp folder, e.g. <literal>/var/temp/N4JSNodeRun123/</literal></simpara>
-</listitem>
-<listitem>
-<simpara>create <literal>node_modules</literal> folder inside working directory, to which projects will be linked</simpara>
-</listitem>
-<listitem>
-<simpara>generate script, e.g. <literal>n4jsELF.js</literal> that will be responsible for booting execution (see <xref linkend="sec:N4JS_Execution_And_Linking_File"/>)</simpara>
-</listitem>
-<listitem>
-<simpara>runner will put <literal>/var/temp/N4JSNodeRun123/node_modules</literal> into <literal>NODE_PATH</literal></simpara>
-</listitem>
-<listitem>
-<simpara>execute <literal>/var/temp/N4JSNodeRun123/n4jsELF.js</literal> with NodeJS</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For example with NodeJS environment if all projects from dependency graph are accessible in local file system, their
-paths would need to be put in NodeJS <emphasis>NODE_PATH</emphasis> environment variable. In addition to configuring execution environment
-<emphasis>Runner</emphasis> generates N4JS Elf file that is used by environment to bootstrap n4js execution
-(see <xref linkend="sec:N4JS_Execution_And_Linking_File"/>).
-[[fig:od_sampleNodeProjectExecution]</simpara>
-<figure role="center">
-<title>Sample NodeJS Project Execution</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/14_execution/images/od_sampleNodeProjectExecution.svg"/>
-</imageobject>
-<textobject><phrase>od sampleNodeProjectExecution</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-</section>
-<section xml:id="sec:N4JS_Execution_And_Linking_File" role="language-n4js">
-<title>N4JS Execution And Linking File</title>
-<simpara>JS execution environment not only needs to know from where it needs to obtain code to execute, but also <emphasis>what is the entry point to the code that is supposed to be executed</emphasis> and <emphasis>what code needs to be loaded before entry point is called</emphasis>.</simpara>
-<simpara>All this information is generated by the runner based on the executed project dependency graph. The way this information
-is presented depends on concrete JS execution environment used, and on its configuration (e.g. user provided options, or
-configuration derived in other ways). But in either case file is generated with that information. Figure <xref linkend="fig:n4js_elf"/>
-shows examples how this information would look like for both testers and runners for both NodeJS or Chrome.</simpara>
-<figure xml:id="fig:n4js_elf" role="center">
-<title>N4JS ELF examples</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/14_execution/images/n4js_elf.svg"/>
-</imageobject>
-<textobject><phrase>n4js elf</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>First segment of the n4js elf is responsible for loading <emphasis>RuntimeEnvironment</emphasis> bootstrap code. Since <emphasis>RuntimeEnvironment</emphasis>s can extend each other, generated information would follow those dependencies. It is possible that <emphasis>RuntimeEnvironment</emphasis>s need to do some special work in regards of of provided <emphasis>RuntimeLibraries</emphasis>s, e.g. initiate initiate polyfills. That code can be either directly in <emphasis>RuntimeEnvironment</emphasis> init code, or its init code can call modules from provided runtime libraries.</simpara>
-<simpara>Second segment of the n4js elf is responsible for loading <emphasis>RuntimeEnvironment</emphasis> exec module. This is special module defined in package.json of the environment, that is used to call into user projects entry point directly, or (as in test case) call into runners of the test library.</simpara>
-<simpara>Last segment of the n4js elf is responsible for passing run/test data (generated by IDE/CLI) into initialised previously exec module.</simpara>
-<simpara>While first two segments are resolved from project dependencies and can be covered by generic approach on IDE/CLI side, last segment requires strong relation between given runner/tester and <emphasis>RuntimeEnvironment</emphasis> / <emphasis>TestEnvironment</emphasis>. While some generic approaches can be used, for the moment we don’t specify concrete convention there.</simpara>
-<section xml:id="subsec:NodeJS_Specific_ELF" role="language-n4js">
-<title>NodeJS Specific ELF</title>
-<simpara>Concrete environments may need specific setup that is not common for other environemtns. For example for NodeJS runner
-needs to configure the node lookup paths for the module resolution. This is achieved by creating at runtime symlinks
-from <literal>node_modules</literal> pointing to concrete dependencies required during execution.</simpara>
-</section>
-</section>
-<section xml:id="sec:Runners-execution" role="language-n4js">
-<title>Runners</title>
-<simpara>It is specified above, that <emphasis>Runner</emphasis> prepares concrete JS execution environment for executing given code and triggers execution process. What is not clear so far is how appropriate runner is selected for given project. In <link linkend="_n4components">N4 Components</link> it was specified that N4JS projects do not depend directly on specific runners or JS execution environments. Instead, N4JS tooling should be able to select appropriate runner based on given project transitive dependencies. In this section we specify overall design of runners for both N4JS IDE and CLI tooling and how runners are selected for projects.</simpara>
-<simpara>INFO: In general any n4js code execution is governed by <emphasis>runners</emphasis> and <emphasis>testers</emphasis> depending on the use case.
-In this chapter <emphasis>runners</emphasis> are described in detail.
-Information from this chapter applies to <emphasis>Testers</emphasis>, unless stated otherwise in chapter dedicated to testing N4JS code (<link linkend="_tests">Tests</link>), were we specify
-testing specific use cases.</simpara>
-<section xml:id="subsec:N4_Runtime_Environments_Convention">
-<title>N4 Runtime Environments Convention</title>
-<simpara>Dependency between <emphasis>Runner</emphasis> and <emphasis>Runtime Environment</emphasis> crosses technical boundary between N4JS Projects (N4JS code) and N4JS tooling (IDE and CLI tools implemented with e.g. Java). We introduce convention to implement this dependency, yet letting N4JS projects and N4JS tools internals to be relatively independent.</simpara>
-<figure xml:id="fig:cd_EnvironmentConvention" role="center">
-<title>Runtime Environments Convention</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/14_execution/images/cd_EnvironmentConvention.svg"/>
-</imageobject>
-<textobject><phrase>cd EnvironmentConvention</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><xref linkend="fig:cd_EnvironmentConvention"/> convention that is used to communicate run time configuration of the N4JS projects (grey colour) and N4JSIDE (pink colour). JS projects declare dependencies on provided list of <emphasis>Runtime Libraries</emphasis>. Each combination of those corresponds to one predefined <emphasis>Runtime Environment</emphasis> N4JS component. On N4JSIDE side there is separate list of <emphasis>runtime environment</emphasis>s maintained. Both lists correspond one to one to each other.</simpara>
-</section>
-<section xml:id="subsec:Passing_Information_from_IDE_to_Execution_Code_in_Runtime_Environment" role="language-n4js">
-<title>Passing Information from IDE to Execution Code in Runtime Environment</title>
-<simpara>When launching an N4JS file, the IDE will compute some information on the containing N4JS project and its direct and indirect dependencies as well as the runtime environment in use. This information will be passed on to the execution module defined in the runtime environment, i.e. the code specified via property in the runtime environment’s package.json file. The information will be passed via a global variable <literal>$executionData</literal>. The value will be a Javascript object with the following properties:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>userSelection</literal>: the module the user had selected when initiating the launch. This will usually be the <literal>module to run</literal> , but in case of testing it will be the project, folder, or file the user had selected.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>projectNameMapping</literal>: an object in which every key is the name of an API project among the direct or indirect dependencies of the project being run, and every value is the name of the corresponding implementation project being used. When running N4JS projects that do not make use of the API / implementation project technique, then this property will either hold an empty object or be undefined.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>testTree</literal> (only when running tests): the test tree as defined in <link linkend="_tests">Tests</link> containing information on the tests to be run, i.e. test classes, test methods, etc. The test tree will be encoded as JSON, so the value of this property will be of type string and should be passed to <literal>JSON.parse()</literal>.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>All calculations described above are based on the workspace available. This includes library manager functionality, see <link xl:href="../20_externalLibraries/externalLibraries.xml#:External_Library_Workspace">External Library Workspace</link>.
-In specific setups, where workspace is not available runners provide helper utility <literal>org.eclipse.n4js.runner.RunnerFileBasedShippedCodeConfigurationHelper.configureFromFileSystem()</literal> that allows to configure given <literal>RunConfiguration</literal> using
-plain file system to the external libraries. Note that in order to do this in a way that allows to re-use all computation logic based on <link xl:href="../12_n4components/n4components.xml#:N4MFContainerManagement">N4Containers</link>,
-runners infrastructure provides its own subclasses of the few component types. Those specialized types are used only in scope of <literal>RunnerFileBasedShippedCodeConfigurationHelper</literal> and are not exposed to the rest of the system.</simpara>
-<simpara>Specific runners, e.g. the NodeJS or Chrome runner, may choose to provide more information via the execution data object.</simpara>
-</section>
-<section xml:id="subsec:Runners_Design">
-<title>Runners Design</title>
-<simpara>As specified in section before N4JS projects will need to be executed on various JS execution environments, for which dedicated runners will be needed. While they will differ how they interact with concrete JS environment, they will have common parts when it comes to interaction with N4JS IDE or CLI. Those parts are provided in form of abstract <emphasis>IDERunner</emphasis> <emphasis>CLIRunner</emphasis> and <emphasis>Runner</emphasis> <emphasis>components</emphasis> (or bundles) that specific runners should use to interact with N4JS IDE or CLI.</simpara>
-<simpara>Runner by design consists of three parts:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis>core</emphasis> part (green colour) - contains most logic, resources (e.g. JS execution environment binary)</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>IDE</emphasis> part (blue colour) - responsible for working with N4JS IDE (enabling runner in ui, providing views)</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>CLI</emphasis> part (yellow colour) - responsible for working with N4JS CLI (get command line parameters, provide console output)</simpara>
-</listitem>
-</itemizedlist>
-<figure xml:id="cd_RunnersIdeCli" role="center">
-<title>Runner for N4JS IDE and CLI tooling</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/14_execution/images/cd_RunnersIdeCli.svg"/>
-</imageobject>
-<textobject><phrase>cd RunnersIdeCli</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Specific runner is connected to running N4JS IDE or CLI via extension points. This is done either by using them directly, or by using types exposed by abstract runner component.</simpara>
-</section>
-</section>
-<section xml:id="sec:Legacy_Execution_Engine" role="language-n4js">
-<title>Legacy Execution Engine</title>
-<simpara>Compilation of N4JS may target many platforms. For the moment it is hard to discuss what they will be exactly or if N4JSIDE will provide some integration or hooks to those platforms. On the other hand we want to have some execution environment for internal use to validate behaviour of compiled code. Since we know that V8 based platforms (e.g. Chrome, NodeJS) will be in our target platforms set we want to be able to execute compiled code on similar environment. As standalone V8 integration is quite challenging, we have decided to integrate in N4JSIDE NodeJS as execution environment. This is considered internal feature used for testing compilation of N4JS and N4JSIDE.</simpara>
-</section>
-<section xml:id="sec:Design" role="language-n4js">
-<title>Design</title>
-<simpara>We provide NodeJS binaries for various OSes. Direct access to binaries is not exposed. Selection and institutionalization of the binary is done internally and is not configurable. Instead bundle containing binaries provides classes required to run code (in form of <literal>String</literal> or <literal>File</literal> with the code). Clients That want to do this may either use provided <literal>Engine</literal> class or can implement their own engine based on provided infrastructure. Main class that used in engine implementation is <literal>EngineCommandBuilder</literal>. This class is responsible for building proper command line commands that engine implementation must execute to run code with NodeJS.</simpara>
-<simpara><xref linkend="fig:cd_executionengine"/> shows the most important classes of the NodeJS integration.</simpara>
-<figure xml:id="fig:cd_executionengine" role="center">
-<title>NodeJS execution integration</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/14_execution/images/cd_executionengine.svg"/>
-</imageobject>
-<textobject><phrase>cd executionengine</phrase></textobject>
-</mediaobject>
-</figure>
-<section xml:id="sec:Usage_Outside_N4JSIDE">
-<title>Usage Outside N4JSIDE</title>
-<simpara>In this use case we use provdied <literal>Engine</literal> class that allows to execute js code in form of <literal>String</literal> or <literal>File</literal> with the code. In return user receives <literal>EngineOutput</literal> object with two lists of strings containing standard output and error output of the node process, that were captured during execution.</simpara>
-<simpara>In this usage scenario execution api assumes valid JS code. User needs to ensure compilation of code prior to execution, if needed.</simpara>
-<simpara>That functionality is used in internal jUnit tests and in xpect tests of the compiler.</simpara>
-<section xml:id="sec:Use_Node_with_Maven">
-<title>Use Node with Maven</title>
-<simpara>Note on maven usage. For maven based builds we need to ensure that binary resources are available and are unpacked. To do this in pom of the project that will be calling engine we must include following listing:</simpara>
-<programlisting language="xml" linenumbering="unnumbered"> <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-dependency-plugin</artifactId>
- <executions>
- <execution>
- <id>unpack</id>
- <phase>process-test-classes</phase>
- <goals>
- <goal>unpack</goal>
- </goals>
- <configuration>
- <artifactItems>
- <artifactItem>
- <groupId>org.eclipse.n4js</groupId>
- <artifactId>org.eclipse.n4js.js.engine</artifactId>
- <version>0.0.1-SNAPSHOT</version>
- <overWrite>true</overWrite>
- <outputDirectory>
- ${project.build.directory}/classes
- </outputDirectory>
- </artifactItem>
- </artifactItems>
- </configuration>
- </execution>
- </executions>
- </plugin></programlisting>
-</section>
-</section>
-<section xml:id="sec:Usage_Inside_N4JSIDE">
-<title>Usage Inside N4JSIDE</title>
-<simpara>In Eclipse platfrom based environment we use custom implementation of the engine, <literal>PlatformEngine</literal>. This implementation unlike default <literal>Platform</literal> is non blocking implementation that forwards output to platform console and allows platform to control lifecycle of the running engine. Additionally this version uses its own implementation of the <literal>ResourceUrlResolver</literal>. It is required to properly resolve urls that point inside platform bundles.</simpara>
-<simpara>This scenario we assume that user will run N4JS files or JS files. We have created proper UI hooks that allow user to do this either from editor or as selection menu. Based on name of the file that user commands to execute we find proper compiled file (compiled with our ES5 compiler - it is not configurable). When found we execute this file in our execution engine. If it is not found, execution engine will write appropriate error to N4JSIDE console.</simpara>
-</section>
-</section>
-<section xml:id="sec:Runtime_Injection" role="langauge-n4js">
-<title>Runtime Injection</title>
-<simpara>There is need to inject into runtime environment some special code, for example when compiling N4JS to ES5 (see N4JavaScriptSpecification,chapter N4 JS Compilation). To achieve this wee need to inject desired code when calling engine to run desired compiled code. Injection mechanism depends a lot on way we run engine. In this section injection of runtime is discussed based on NodeJs that is used as runtime environment.</simpara>
-<section xml:id="sec:Running_String_Code">
-<title>Running String Code</title>
-<simpara>We allow code execution where code is provided in form of <literal>String</literal>. In this case we are calling nodejs with parameters . To enrich execution environment in this case we are appending special runtime code at the end of file. It is important to append it at the end, to avoid changing line numbers of original code and decrease other potential side effects. So actual invocation of nodejs looks like</simpara>
-<simpara>This mechanism assumes:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>injected code starts with new line - this makes ASI mechanism to finish user last statement if it was not properly finished by user, otherwise just creates</simpara>
-</listitem>
-<listitem>
-<simpara>injected code does not have to be initiated manually - all exposed api is in named function declarations</simpara>
-</listitem>
-</orderedlist>
-<simpara><emphasis>Explanation</emphasis></simpara>
-<simpara>In first assumption we make workaround for user code that does not contain new line or semicolon at the end of last statement. This kind of code is incorrect and would result in last statement of user code and first statement of injected code to be interpreted as one JS statement. In most cases that would be invalid code. By having new line as first character of injected code, we are taking advantage of JS AutomaticSemicolonInjection mechanism. If user code AST is not finished properly this mechanism will finish close user AST. If user AST is finished properly, ASI will just insert empty statement between user code and injection code. In both cases we end up with proper AST.</simpara>
-<simpara>Second assumption avoids need for further user code modifications, as injected does not have to be manually called. Instead we take advantage of variable and function hoisting mechanism of JS. This assures that even though user code is first in AST, JS environment will first initiate named functions therefore when user code calls injected code it is already defined in scope in which user code executes.</simpara>
-</section>
-<section xml:id="sec:Running_File_Code">
-<title>Running File Code</title>
-<simpara>Second method of code execution is to execute provided file with user code. Normal way of doing that with NodeJS is to make call. But since we need to inject special code without rewriting files, we use different mechanism. Basically we are executing injected code and in the same scope using node api. Additionally we are attaching injected code to global scope in node, ensuring this way that required file is executed in scope which contains injected code. Putting this all together we are making following call:</simpara>
-<simpara>This mechanism assumes that injected code attaches all exposed API to global scope .</simpara>
-</section>
-<section xml:id="sec:Injection_Code_Example">
-<title>Injection Code Example</title>
-<simpara>Following is simple example of properly formed injection code.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">;
-function foo(){}
-function bar(){}
-function baz(){}
-
-(function(){
- GLOBAL.foo = foo;
- GLOBAL.bar = bar;
- GLOBAL.baz = baz;
-})();
-;</programlisting>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>first line is empty line to trigger ASI</simpara>
-</listitem>
-<listitem>
-<simpara>second line (optional) enters</simpara>
-</listitem>
-<listitem>
-<simpara>lines 3-5 are defining runtime api in current scope (in which user code provided as a string is executed)</simpara>
-</listitem>
-<listitem>
-<simpara>lines 6 (optional) is just a visual sugar</simpara>
-</listitem>
-<listitem>
-<simpara>lines 7-11 are adding runtime api to global scope (to expose it when runnig user file with code)</simpara>
-</listitem>
-<listitem>
-<simpara>lines 12-13 (optional) are there to separate injected code and invokation of user file (if running user provided file with code)</simpara>
-</listitem>
-</orderedlist>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_tests">
-<title>Tests</title>
-<warning>
-<simpara>This chapter may be outdated.</simpara>
-</warning>
-<simpara>In order to run all tests from command line, use maven:</simpara>
-<screen>mvn clean verify</screen>
-<simpara>You may have to increase the memory for maven via <literal>export MAVEN_OPTS="-Xmx2048m"</literal> (Unix) or <literal>set MAVEN_OPTS="-Xmx2048m"</literal> (Windows).</simpara>
-<simpara>Do not run the tests via <literal>mvn clean test</literal> as this may lead to some failures.</simpara>
-<section xml:id="sec:Performance_Tests" role="language-n4js">
-<title>Performance Tests</title>
-<simpara>There are two kind of performance tests:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Synthetic Tests: an arbitrary number of test classes is generated, and then some modifications are performed on these classes.</simpara>
-</listitem>
-<listitem>
-<simpara>Real World Tests: tests are based on a snapshot version of our platform libraries</simpara>
-</listitem>
-</orderedlist>
-<section xml:id="sec:Synthetic_Performance_Tests">
-<title>Synthetic Performance Tests</title>
-<simpara>The idea of the synthetic performance tests is to test the performance of specific functionality with a defined number classes, specially designed for the functionality under test.</simpara>
-<simpara>The overall structure of the synthetic performance test is</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>generate test classes</simpara>
-</listitem>
-<listitem>
-<simpara>compile these classes</simpara>
-</listitem>
-<listitem>
-<simpara>modify the test classes</simpara>
-</listitem>
-<listitem>
-<simpara>measure incremental build time</simpara>
-</listitem>
-</orderedlist>
-<simpara>Step 3) and 4) can be done in a loop. Also, step 2) can be looped (with clean build).</simpara>
-<simpara>The test classes are spread over clusters and projects. The following categories are used:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Cluster</simpara>
-</entry>
-<entry>
-<simpara>A cluster is a set of projects, each project of a cluster may depend on another project of the cluster. There are no dependencies between projects of different clusters</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Project</simpara>
-</entry>
-<entry>
-<simpara>A project simply is a N4JS project, containing packages. A project may depend on other projects.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Package</simpara>
-</entry>
-<entry>
-<simpara>A package is a folder in a source folder of a project. A package contains classes.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Class</simpara>
-</entry>
-<entry>
-<simpara>A class is defined in a file, usually one class per file. The file, and with it the class, is contained in a package. The class contains members.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Member</simpara>
-</entry>
-<entry>
-<simpara>A member is either a field or method of a class. A method may has a body, which may contain variables with references to other classes.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<section xml:id="sec:Design_of_Generator" role="language-n4js">
-<title>Design of Generator</title>
-<simpara><link linkend="fig:cd_performancetest_generator">Performance Generator</link> shows the classes of the performance test generator.</simpara>
-<informalfigure xml:id="fig:cd_performancetest_generator">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/15_tests/images/cd_performancetest_generator.svg"/>
-</imageobject>
-<textobject><phrase>cd performancetest generator</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>The package is designed as follows:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>N4ProjectGenerator</literal> main control class for generation</simpara>
-</listitem>
-<listitem>
-<simpara><literal>TestDescriptor</literal> and subclasses: In order to <emphasis>keep memory consumption of the test class generator low</emphasis>, there is no graph structure created for the test elements. Instead, each element is uniquely named by a number, this number (actually a tuple of numbers) is stored in <literal>TestDescriptors</literal> and sub classes. There is a descriptor for each element of the tests.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>AbstractModifier</literal> and subclasses generarate the tests. The idea is as follows:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>Modifier</literal> generates all files, with complete references and no issues (complete)</simpara>
-</listitem>
-<listitem>
-<simpara>sub classes of <literal>Modifier</literal> skip certain generations or add modifications, leading to issues or solving them</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</orderedlist>
-<simpara>In order to compute the name of a class from its descriptor, as well as retrieving a class based on an absolute number, the modifiers use utility methods provided by <literal>PerformanceTestConfiguration</literal>. Note that computing the names and numbers depends on a configuration!</simpara>
-</section>
-<section xml:id="sec:Design_of_Performance_Test_Execution">
-<title>Design of Performance Test Configuration and Execution</title>
-<simpara><xref linkend="fig:cd_performancetest_configAnRun"/> shows the classes of the performance test configuration and execution.</simpara>
-<figure xml:id="fig:cd_performancetest_configAnRun">
-<title>Class Diagram of Performance Test Configuration and Execution</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/15_tests/images/cd_performancetest_configAnRun.svg"/>
-</imageobject>
-<textobject><phrase>cd performancetest configAnRun</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The package is designed as follows:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>PerformanceTestConfiguration</literal> stores the test configuration. The configuration stores how many clusters, packages etc. are to be generated. It also provides methods for generating names from the descriptors mentioned above.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>PerformanceMeter</literal> executes the test, listening to the (build) job to be finished etc.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>AbstractGeneratingPerformanceTest</literal> Base test class contains setup, teardown and utility methods.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>PerformanceTest</literal> Test class containing tests.</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:JUnit_Configuration">
-<title>JUnit Configuration</title>
-<simpara>We are using JUnitBenchamrks (<link xl:href="http://labs.carrotsearch.com/junit-benchmarks.html/">http://labs.carrotsearch.com/junit-benchmarks.html/</link>) to extend adjust plain JUnit behavior specifically to the performance tests needs.</simpara>
-</section>
-<section xml:id="sec:JUnitBenchmark_Test_Configuration">
-<title>JUnitBenchmark Test Configuration</title>
-<simpara>JUnitBenchmark test configuration performed by annotating test method with <literal>@BenchmarkOptions</literal>. Parameters for that annotation include:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>warmupRounds</literal> how many times test will be executed without taking measurement</simpara>
-</listitem>
-<listitem>
-<simpara><literal>benchmarkRounds</literal> how many times test will be executed, measurements taken will be used in results report</simpara>
-</listitem>
-<listitem>
-<simpara><literal>callgc</literal> Call <literal>System.gc()</literal> before each test. This may slow down the tests in a significant way.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>concurrency</literal> specifies how many threads to use for tests.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>clock</literal> specifies which clock to use.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Typical configuration for our performance tests might look like:</simpara>
-<screen> @BenchmarkOptions(benchmarkRounds = 5, warmupRounds = 2)
- @Test
- public void test() throws Exception {
- //test...
- }</screen>
-</section>
-<section xml:id="sec:JUnitBenchmark_Report_Configuration">
-<title>JUnitBenchmark Report Configuration</title>
-<simpara>By annotating TestClass in proper way, JUnitBenchamrks will generate html reports with performance results. There are two reports that can be generated:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>@BenchmarkMethodChart</literal> report will contain results for every method from one test run (but all <literal>benchmarkRounds</literal> defined)</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>filePrefix</literal> defines report file name</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><literal>@BenchmarkHistoryChart</literal> report will contain trend of results from multiple test runs (it is aggregation of multiple instances of <literal>@BenchmarkMethodChart</literal> report)</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>filePrefix</literal> defines report file name</simpara>
-</listitem>
-<listitem>
-<simpara><literal>labelWith</literal> defines label that will mark separate runs</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</orderedlist>
-<simpara><emphasis>labelWith</emphasis> property can have value propagated from run configuration/command line. example configuration might be <literal>@BenchmarkHistoryChart(filePrefix = benchmark-history, labelWith = LabelType.CUSTOM_KEY)</literal></simpara>
-</section>
-<section xml:id="sec:JUnitBenchmark_Run_Configuration">
-<title>JUnitBenchmark Run Configuration</title>
-<simpara>It is possible to specify additional options for performance test run</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>-Djub.consumers=CONSOLE,H2</literal> specifies where results will be written, <emphasis>H2</emphasis> indicates H2 database to be used</simpara>
-</listitem>
-<listitem>
-<simpara><literal>-Djub.db.file=.benchmarks</literal> specifies name of the H2 database file</simpara>
-</listitem>
-<listitem>
-<simpara><literal>-Djub.customkey=</literal> value of that property scan be used as label in <literal>@BenchmarkHistoryChart</literal></simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:JUnitBenchmark_Example">
-<title>JUnitBenchmark Example</title>
-<simpara>configuration example:</simpara>
-<screen>@BenchmarkMethodChart(filePrefix = "benchmark-method")
-@BenchmarkHistoryChart(filePrefix = "benchmark-history", labelWith = LabelType.CUSTOM_KEY)
-public class PerformanceTest extends AbstractGeneratingPerformanceTest {
-
- public PerformanceTest() {
- super("PerfTest");
- }
-
- @Rule
- public TestRule benchmarkRun = new BenchmarkRule();
-
- @Test
- @BenchmarkOptions(benchmarkRounds = 5, warmupRounds = 2)
- public void Test1() throws Exception {
-
- //Test...
- }
-
- @Test
- @BenchmarkOptions(benchmarkRounds = 5, warmupRounds = 2)
- public void Test2() throws Exception {
-
- //Test...
- }
-}</screen>
-<simpara>executing this code in Eclipse with configuration:</simpara>
-<programlisting language="bash" linenumbering="unnumbered">-Xms512m -Xmx1024m -XX:MaxPermSize=512m $-$Djub.consumers=CONSOLE,H2 $-$Djub.db.file=.benchmarks $-$Djub.customkey=${current_date}</programlisting>
-<simpara>will cause :</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>both tests to be executed 2 times for the warmup</simpara>
-</listitem>
-<listitem>
-<simpara>both of tests being executed 5 times with measurement taken</simpara>
-</listitem>
-<listitem>
-<simpara>results written to console</simpara>
-</listitem>
-<listitem>
-<simpara>results stored in local H2 db file (created if doesn’t exist)</simpara>
-</listitem>
-<listitem>
-<simpara>generated <emphasis>benchmark-method.html</emphasis> with performance results of every test in that execution</simpara>
-</listitem>
-<listitem>
-<simpara>generated <emphasis>benchmark-history.html</emphasis> with performance results of every execution</simpara>
-</listitem>
-<listitem>
-<simpara>separate test executions will be labeled in <emphasis>benchmark-history.html</emphasis> with their start time</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Note_on_Jenkins_Job">
-<title>Note on Jenkins Job</title>
-<simpara>For performance tests it is important not to get pass/fail result in terms of being below given threshold, but also to examine trend of those results. We achieve this by tooling described above. In order to keep this data independent of the build machine or build system storage, we are using separate repository to store performance artifacts. Jenkins in copying previous test results into workspace, runs performance tests, then commits and pushes combined results (adds current results to previous results) to repository.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="sec:ECMA_Tests" role="language-n4js">
-<title>ECMA Tests</title>
-<simpara>ECMAScript Language test262 is a test suite intended to check agreement between JavaScript implementations and ECMA-262, the ECMAScript Language Specification (currently 5.1 Edition).The test suite contains thousands of individual tests, each of which tests some specific requirements of the ECMAScript Language Specification. For more info refer to <link xl:href="http://test262.ecmascript.org/">http://test262.ecmascript.org/</link></simpara>
-<simpara>Uses of this suite may include:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>grammar tests</simpara>
-</listitem>
-<listitem>
-<simpara>validation tests</simpara>
-</listitem>
-<listitem>
-<simpara>run-time tests</simpara>
-</listitem>
-</orderedlist>
-<simpara>ECMA test262 suite source code can be found here: <link xl:href="http://hg.ecmascript.org/tests/test262">http://hg.ecmascript.org/tests/test262</link></simpara>
-<section xml:id="sec:Grammar_Tests">
-<title>Grammar Tests</title>
-<simpara>Based on the JS files included in test262 suite we are generating tests that feed provided JS code into the parser. This operation will result in</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>parser throwing exceptions</simpara>
-</listitem>
-<listitem>
-<simpara>parsed output will contain standard output</simpara>
-</listitem>
-</orderedlist>
-<simpara>First case indicates that parsing provided JS code was not possible. This is considered to be Test Error.</simpara>
-<simpara>Second case case indicates that parsing of the provided code was successful, and will result either</simpara>
-<itemizedlist>
-<listitem>
-<simpara>output with no errors - code adhered parser grammar</simpara>
-</listitem>
-<listitem>
-<simpara>output with errors - code violated parser grammar</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Given test must interpret those results to provide proper test output.</simpara>
-<section xml:id="sec:Negative_Tests">
-<title>Negative Tests</title>
-<simpara>It is important to note that some of the tests are positive and some are negative. Negative test cases are marked by the authors with <emphasis>@negative</emphasis> JSDoc like marker therefore parser tests must be aware of that to avoid both false positives and false negatives results.</simpara>
-</section>
-<section xml:id="sec:Test_Exclusion">
-<title>Test Exclusion</title>
-<simpara>To exclude validation tests or run-time related test, implementation is blacklist approach to exclude some of the ECMA test262 tests from execution.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="sec:Integration_Tests" role="language-n4js">
-<title>Integration Tests</title>
-<simpara>Integration tests based on the stdlib and online-presence code bases can be found in bundle <literal>org.eclipse.n4js.hlc.tests</literal>
-in package <literal>org.eclipse.n4js.hlc.tests.integration</literal> (headless case) and in bundle <literal>org.eclipse.n4js.ui.tests</literal> in
-package <literal>org.eclipse.n4js.ui.tests.integration</literal> (plugin-UI tests running inside Eclipse). The headless
-tests also execute mangelhaft tests, the UI tests only perform compilation of the test code.</simpara>
-<simpara>More information can be found in the API documentation of classes <literal>AbstractIntegrationTest</literal> and <literal>AbstractIntegrationPluginUITest</literal>.</simpara>
-</section>
-<section xml:id="sec:Test_Helpers" role="language-n4js">
-<title>Test Helpers</title>
-<simpara>Test helpers contain utility classes that are reused between different test plug-ins.</simpara>
-<section xml:id="sec:Parameterized_N4JS_Tests">
-<title>Parameterized N4JS tests</title>
-<simpara>Xtext JUnit test runer injects test a ParserHelper that allows to run N4JS parser on given input and obtain information abut parsing results. In some cases we want to run this kind of tests on large input data. To address this we provide two utilities ParameterizedXtextRunner and TestCodeProvider. They allow write data driven parser tests.</simpara>
-<section xml:id="sec:ParameterizedXtextRunner">
-<title>ParameterizedXtextRunner</title>
-<simpara>This This junit runner serves two purposes:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>injecting ParserHelper</simpara>
-</listitem>
-<listitem>
-<simpara>creating multiple test instances for each input data provided</simpara>
-</listitem>
-</itemizedlist>
-<simpara>This class is based on @link org.eclipse.xtext.testing.XtextRunner and @link org.junit.runners.Parameterized</simpara>
-</section>
-<section xml:id="sec:TestCodeProvider">
-<title>TestCodeProvider</title>
-<simpara>This class is repsonsible for extracting ZipEntry from provided ZipFile. Additinally it can filter out entries that match strings in provided black list file. Filtering out ZipEntries assumes that blacklist file contians Path of ZipEntry in ZipFile as string in one line. Lines starting with <emphasis>#</emphasis> in black list file are ignored by TestCodeProvider.</simpara>
-</section>
-<section xml:id="sec:Example_Of_Parameterized_Parser_Test">
-<title>Example of parameterized parser test</title>
-<programlisting language="n4js" linenumbering="unnumbered">@RunWith(XtextParameterizedRunner.class)
-@InjectWith(N4JSInjectorProvider.class)
-public class DataDrivenParserTestSuite {
-
- /**
- * Zip archives containing test files.
- */
- public static final Collection<String> TEST_DATA_RESOURCES = Arrays.asList("foo.zip", "bar.zip");
-
- /**
- * Blacklist of files requiring an execution engine.
- */
- public static final String BLACKLIST_FILENAME = "blacklist.txt";
-
- /**
- * Every generated test will use different ZipEntry as test data
- */
- final ZipEntry entry;
-
- /**
- * Name of resource containing corresponding ZipEntry
- */
- final String resourceName;
-
- @Inject
- protected ParseHelper<Script> parserN4JS;
-
- Collection<String> blackList;
-
- static final Logger logger = Logger.getLogger("someLogger");
-
- public CopyOfLibraryParsingTestSuite(ZipEntry entry, String resourceName, Collection<String> blackList) {
- this.entry = entry;
- this.resourceName = resourceName;
- this.blackList = blackList;
- }
-
- @Rule
- public TestRule blackListHandler = new TestRule() {
- @Override
- public Statement apply(final Statement base, Description description) {
- final String entryName = entry.getName();
- if (blackList.contains(entryName)) {
- return new Statement() {
- @Override
- public void evaluate() throws Throwable {
- try {
- base.evaluate();
- } catch (AssertionError e) {
- // expected
- return;
- }
- }
- };
- } else {
- return base;
- }
- }
- };
-
- /**
- * Generates collection of ZipEntry instances that will be used as data
- * provided parameter is mapped to name of the test (takes advantage of fact
- * that ZipEntry.toString() is the same as entry.getName())
- *
- * @return
- * @throws URISyntaxException
- * @throws ZipException
- * @throws IOException
- */
- @Parameters(name = "{0}")
- public static Collection<Object[]> data() throws URISyntaxException, ZipException, IOException {
- return TestCodeProvider.getDataFromZippedRoots(TEST_DATA_RESOURCES, BLACKLIST_FILENAME);
- }
-
- /**
- * generated instances of the tests will use this base implementation
- *
- * @throws Exception
- */
- @Test
- public void test() throws Exception {
- assertNotNull(this.entry);
- assertNotNull(this.resourceName);
- assertNotNull(this.parserN4JS);
-
- //actual test code
-
- }
-}</programlisting>
-</section>
-</section>
-</section>
-<section xml:id="sec:Issue_Suppression" role="language-n4js">
-<title>Issue Suppression</title>
-<simpara>It can be useful to suppress certain issues before tests are ran, so that test expectations don’t have to consider inessential warnings. This means that the validator still returns a full list of issues, but before passing them to the testing logic, the issues are filtered.</simpara>
-<simpara>When working with JUnit tests, the custom InjectorProvider <literal>N4JSInjectorProviderWithIssueSuppression</literal> can be used to configure them to suppress issues.</simpara>
-<simpara>The codes that are suppressed are globally specified by the<?asciidoc-br?>
-<literal>DEFAULT_SUPPRESSED_ISSUE_CODES_FOR_TESTS</literal> constant in <literal>N4JSLanguageConstants</literal>.</simpara>
-<simpara>When working with Xpect tests, the XpectSetupFactory <literal>SuppressIssuesSetup</literal> can be used. See <link linkend="sec:Xpect_Issue_Suppression">Xpext Issue Suppression</link> for more details on Xpect issue suppression.</simpara>
-</section>
-<section xml:id="sec:Xpect_Tests" role="language-n4js">
-<title>Xpect Tests</title>
-<simpara>For many tests, Xpect [<link linkend="Xpect">Xpect</link>] is used. Xpect allows for defining tests inside the language which is the language under test. That is, it is possible to refer to a JUnit test method in a special annotated comment, along with arguments passed to that method (typically expectations and the concrete location). Xpect comes with a couple of predefined methods which could be used there, e.g., tests for checking whether some expected error messages actually are produced. We have defined (and will probably define more) N4JS specific test methods.</simpara>
-<simpara>In the following, we describe the most common Xpect test methods we use. Note that we do not use all types of tests shipped with Xpect. For example, AST tests (comparing the actual AST with an expected AST, using string dumps) is too hard to maintain.</simpara>
-<simpara>Xpect test can be ignored by inserting a <literal>!</literal> between <literal>XPECT</literal> and the test name, e.g.</simpara>
-<screen>// XPECT ! errors --> '~$message$~' at "~$location$~"</screen>
-<section xml:id="sec:Xpect_Test_Setup">
-<title>Xpect Test Setup</title>
-<simpara>The setup is either defined in the file itself, e.g.,</simpara>
-<screen>/* XPECT_SETUP org.eclipse.n4js.spec.tests.N4JSSpecTest END_SETUP */</screen>
-<simpara>or bundle-wide for a specific language in the plugin.xml (or fragment.xml), e.g.,</simpara>
-<screen><extension point="org.xpect.testSuite">
- <testSuite class="org.eclipse.n4js.spec.tests.N4JSSpecTest" fileExtension="n4js" />
-</extension></screen>
-</section>
-<section xml:id="sec:Xpect_Issue_Suppression">
-<title>Xpect Issue Suppression</title>
-<simpara>To configure an Xpect test class to suppress issues, you have to use the <literal>@XpectImport</literal> annotation to import the XpectSetupFactory <literal>org.eclipse.n4js.xpect.validation.suppression.SuppressIssuesSetup</literal>. Any Xpect test that is executed by this runner will work on the filtered list of issues.</simpara>
-<simpara>Similar to issue suppressing JUnit tests, the suppressed issue codes are specified by<?asciidoc-br?>
-<literal>DEFAULT_SUPPRESSED_ISSUE_CODES_FOR_TESTS</literal> constant in <literal>N4JSLanguageConstants</literal>.</simpara>
-<simpara>For further per-file configuration a custom <literal>XPECT_SETUP</literal> parameter can be used. This overrides the suppression configuration of an Xpect runner class for the current file.</simpara>
-<screen>/* XPECT_SETUP org.eclipse.n4js.tests.N4JSXpectTest
-
-IssueConfiguration {
- IssueCode "AST_LOCAL_VAR_UNUSED" {enabled=true}
-}
-
-END_SETUP
-*/</screen>
-<simpara>In this example the issue code <literal>AST_LOCAL_VAR_UNUSED</literal> is explicitly enabled which means that no issue with this issue code will be suppressed.</simpara>
-</section>
-<section xml:id="sec:Xpect_Provided_Test_Methods">
-<title>Xpect Provided Test Methods</title>
-<section xml:id="errors">
-<title>errors</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>// XPECT errors --> '~$message$~' at "~$location$~"</screen>
-<simpara>Multi line:</simpara>
-<screen>/* XPECT errors ---
-'~$message_1$~' at "~$location_1$~"
-~$\dots$~
-'~$message_n$~' at "~$location_n$~"
---- */</screen>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that one or more errors are issued at given location and compares the actual messages at a given location with the expected messages specified in the test.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Also see <literal>no errors</literal> below.</simpara>
-</section>
-<section xml:id="warnings">
-<title>warnings</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:<?asciidoc-br?></simpara>
-<screen>// XPECT warnings --> '~$Message$~' at "~$Location$~"</screen>
-<simpara>Multi line:</simpara>
-<screen>/* XPECT warnings ---
-'~$message_1$~' at "~$location_1$~"
-~$\dots$~
-'~$message_n$~' at "~$location_n$~"
---- */</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that one or more warnings are issued at given location and compares the actual messages at a given location with the expected messages specified in the test.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-</section>
-<section xml:id="sec:N4JS_Specific_Xpect_Test_Methods">
-<title>N4JS Specific Xpect Test Methods</title>
-<simpara>There are a lot of N4 specific Xpect tests methods available. To get all of these methods, search for references to annotation <literal>org.xpect.runner.Xpect</literal> in the N4 test plugins.</simpara>
-<section xml:id="sec:XPECT_noerrors">
-<title>noerrors and nowarnings</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>// XPECT noerrors --> '~$messageOrComment$~' at "~$location$~"</screen>
-<simpara>Multi line:</simpara>
-<screen>/* XPECT noerrors ---
-'~$messageOrComment_1$~' at "~$location_1$~"
-~$\dots$~
-'~$messageOrComment_n$~' at "~$location_n$~"
---- */</screen>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>NoerrorsValidationTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that at the given location <emphasis>no</emphasis> error (or warning) is issued. This tests is roughly speaker the opposite of <literal>errors</literal>. The idea behind this test is to replace comments in the code, stating that an expression is assumed to be valid, with an explicit test. This is in particular useful when you start working on a task, in which there are (wrong) errors at a given position, or for bug report.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<informalexample>
-<screen>function foo(any o): number {
- if (o instanceof string) {
- // XPECT noerrors --> "effect systems knows that o is a string" at "o"
- return o.length;
- }
- return 0;
-}</screen>
-<simpara>is clearer and more explicit than</simpara>
-<screen>function foo(any o): number {
- if (o instanceof string) {
- // here should be no error:
- return o.length;
- }
- return 0;
-}</screen>
-<simpara>Also, the <literal>noerrors</literal> version will fail with a correct description, while the second one would fail with a general error and no location. Once the feature is implemented, regressions are detected much easier with the explicit version.</simpara>
-</informalexample>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_scope">
-<title>scope</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>// XPECT scope at $location$ --> ~$[$~!~$]$~~$name_1$~, ~$\dots$~, ~$[$~!~$]$~~$name_n$~ ~$[$ ~, ...~$]$~</screen>
-<simpara>Multi line:</simpara>
-<screen>/* XPECT scope $location$ ---
-~$[$~!~$]$~~$name_1$~, ~$\dots$~,
-~$[$~!~$]$~~$name_n$~~$[$ ~, ...~$]$~
---- */</screen>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>PositionAwareScopingXpectTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that the expected elements are actually found in the scope (or explicitly not found, when <literal>!</literal> is used). This is a modified version of the Xpect built-in scope test, ensuring that also elements only put into the scope when they are explicitly requested are found.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<screen>// XPECT scope at 'this.|$data_property_b' --> a, b, $data_property_b, !newB, ...
-return this.$data_property_b + "_getter";</screen>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_scopeWithPosition">
-<title>scopeWithPosition</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">// XPECT scopeWithPosition at $location$ --> ~$[$~!~$]$~~$name_1$~ - ~$pos_1$~, ~$\dots$~, ~$[$~!~$]$~~$name_n$~ - ~$pos_n$~ ~$[$ ~, ...~$]$~</programlisting>
-<simpara>Multi line:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/* XPECT scopeWithPosition $location$ ---
-~$[$~!~$]$~~$name_1$~ - ~$pos_1$~, ~$\dots$~,
-~$[$~!~$]$~~$name_n$~ - ~$pos_n$~ ~$[$ ~, ...~$]$~
---- */</programlisting>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>PositionAwareScopingXpectTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that the expected elements are actually found in the scope (or explicitly not found, when <literal>!</literal> is used). The concrete syntax of the position, which is usually the line number, or the line number prefix with <literal>T</literal> if a type element is referenced, is described in <literal>EObjectDescriptionToNameWithPositionMapper</literal>.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<screen>/* XPECT scopeWithPosition at foo2 ---
- b - 9,
- c - 25,
- foo - T3,
- foo2 - T9,
- ...
----*/
-foo2()</screen>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_scopeWithResource">
-<title>scopeWithResource</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>//</screen>
-<simpara>Multi line:</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>N4JSXpectTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Compares scope including resource name but not line number.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_binding">
-<title>binding</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>//</screen>
-<simpara>Multi line:</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>N4JSXpectTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that a given element is bound to something identified by (simple) qualified name. The check is designed as simple as possible. That is, simply the next following expression is tested, and within that we expect a property access or a direct identifiable element. The compared name is the simple qualified name, that is container (type) followed by elements name, without URIs of modules etc.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_linkedPathname">
-<title>linkedPathname</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>// XPECT linkedPathname at '$location$' --> ~$pathname$~</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>LinkingXpectMethod</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that an identifier is linked to a given element identified by its path name. The path name is the qualified name in which the segments are separated by ’/’. This test does not use the qualified name provider, as the provider may return null for non-globally available elements. It rather computes the name again by using reflection, joining all <literal>name</literal> properties of the target and its containers.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<screen>// XPECT linkedPathname at 'foo()' --> C/foo
-new C().foo();</screen>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_type_of">
-<title>type of</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>// XPECT type of '$location$' --> ~$type$~</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>N4JSXpectTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that the type inferred at location is similar to expected type.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<screen>// XPECT type of 'x' --> string
-var x = 'hello';
-// XPECT type of 'foo()' --> union{A,number}
-var any y = foo();</screen>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_expectedType">
-<title>expectedType</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>-</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Single line</simpara>
-</entry>
-<entry>
-<screen>// XPECT expectedType at 'location' --&gt; Type</screen>
-<literallayout class="monospaced">The location (at) is optional.</literallayout>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>N4JSXpectTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that an element/expression has a certain expected type (i.e. Xsemantics judgment expectedTypeIn).</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_elementKeyword">
-<title>elementKeyword</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>// XPECT elementKeyword at 'myFunction' -> function</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<screen>interface I {
- fld: int;
- get g(): string;
- set s(p:string);
-}
-
-//XPECT elementKeyword at 'string' --> primitive
-var v1: string;
-
-//XPECT elementKeyword at 'I' --> interface
-var i: I;
-
-//XPECT elementKeyword at 'fld' --> field
-i.fld;</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>ElementKeywordXpectMethod</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that an element/expression has a certain element keyword. The expected element keyword is identical
-to the element keyword shown when hovering the mouse over that element/expression in the N4JS IDE. This method is particuarly useful for testing merged elements of union/intersection.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_accessModifier">
-<title>accessModifier</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>// XPECT accessModifier at 'myFunction' -> function</screen>
-<simpara>or</simpara>
-<screen>// XPECT accessModifier -> function</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<screen>// XPECT accessModifier --> publicInternal
-export @Internal public abstract class MyClass2 {
-
-// XPECT accessModifier --> project
-abstract m1(): string;
-
-// XPECT accessModifier at 'm2' --> project
-m2(): string {
- return "";
- }
-}</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>AccessModifierXpectMethod</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that an element/expression has a certain accessibility.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_compileResult">
-<title>compileResult</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>//</screen>
-<simpara>Multi line:</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara>-</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara><emphasis>This test should only be used during development of compiler and not used in the long run, because this kind of test is extremely difficult to maintain.</emphasis></simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_output">
-<title>output</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>//</screen>
-<simpara>Multi line:</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara>-</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>The most important test for compiler/transpiler, but also for ensuring that N4JS internal validations and assumptions are true at runtime.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_outputRegEx">
-<title>outputRegEx</title>
-
-</section>
-<section xml:id="sec:XPECT_calculatedAccessModifier">
-<title>calculatedAccessModifier</title>
-
-</section>
-<section xml:id="sec:XPECT_spec">
-<title>spec</title>
-
-</section>
-<section xml:id="sec:XPECT_deadCode">
-<title>deadCode</title>
-
-</section>
-<section xml:id="sec:XPECT_returnOrThrows">
-<title>returnOrThrows</title>
-
-</section>
-<section xml:id="sec:XPECT_lint">
-<title>lint</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>/* XPECT lint */</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>CompileAndLintTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Passes the generated code through the JSHint JavaScript linter. This test includes for instance checking for missing semicolons and undefined variables. The whole test exclusively refers to the generated javascript code.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:XPECT_lintFails">
-<title>lintFails</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Single line:</simpara>
-<screen>/* XPECT lintFails */</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided By</simpara>
-</entry>
-<entry>
-<simpara><literal>CompileAndLintTest</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Negation of lint. Fails on linting success. Expects linting errors.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-</section>
-<section xml:id="sec:FIXME_Xpect_modifier">
-<title>FIXME Xpect modifier</title>
-<simpara>A modification of the official Xpect framework allows us to use the FIXME modifier on each test. <footnote><simpara>Currently we use our own fork of Xpect <link xl:href="https://github.com/NumberFour/Xpect">https://github.com/NumberFour/Xpect</link> and the respective p2-repository <link xl:href="https://numberfour.github.io/Xpect/updatesite/nightly/">https://numberfour.github.io/Xpect/updatesite/nightly/</link></simpara></footnote></simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Syntax</simpara>
-</entry>
-<entry>
-<simpara>FIXME can be applied on any test just after the XPECT keyword:</simpara>
-<screen>// XPECT FIXME xpectmethod ... --> ...</screen>
-<simpara>Tests will still be ignored if an exclamation mark (!) is put between XPECT and FIXME.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Using FIXME on a test negates the result of the underlying JUnit test framework. Thus a failure will be reported as a <literal>true assertion</literal> and an assertion that holds will be reported as <literal>failure</literal> . This enables to author valuable tests of behaviour, which is still not functional.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<simpara>For instance, if we encounter an error-message at a certain code position, but the code is perfectly right, then we have an issue. We can annotate the situation with a ’fix me’ ’noerrors’ expectation:</simpara>
-<screen>// Perfectly right behaviour XPECT FIXME noerrors -->
-console.log("fine example code with wrong error marker here.");</screen>
-<simpara>This turns the script into an Xpect test. We can integrate the test right away into our test framework and it will not break our build (even though the bug is not fixed).</simpara>
-<simpara>When the issue will be worked on, the developer starts with removing ’FIXME’ turning this into useful unit-test.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>It is crucial to understand that FIXME negates the whole assertion. Example: If one expects an error marker at a certain position using the ’errors’ directive, one must give the exact wording of the expected error-message to actually get the FIXME behaviour working. To avoid strange behaviour it is useful to describe the expected error a comment in front of the expectation and leave the message-section empty.</simpara>
-</section>
-<section xml:id="sec:Expectmatrix_Xpect_Test_Methods">
-<title>Expectmatrix Xpect tests</title>
-<simpara>Applying test-driven development begins with authoring acceptance and functional tests for the work in the current sprint. By this the overall code quality is ensured for the current tasks to solve. Rerunning all collected tests with each build ensures the quality of tasks solved in the past. Currently there is no real support for tasks, which are not in progress but are known to be processed in the near or far future. Capturing non-trivial bug reports and turning them into reproducable failing test-cases is one example.</simpara>
-<simpara>Usually people deactivate those future-task-tests in the test code by hand. This approach doesn’t allow to calculate any metrics about the code. One such metric would be: Is there any reported bug solved just by working on an (seemingly unrelated) scheduled task?</simpara>
-<simpara>To achieve measurements about known problems, a special build-scenario is set up. As a naming convention all classes with names matching <literal>* Pending</literal> are assumed to be Junit tests. In bundle <literal>org.eclipse.n4js.expectmatrix.tests</literal> two different Xpect-Runners are provided, each working on its own subfolder. Usual Xpect-tests are organised in folder xpect-test while in folder xpect-pending all future-tests are placed. A normal maven-build processes only the standard junit and xpect tests. Starting a build with profile <literal>execute-expectmatrix-pending-tests</literal> will additionally execute Xpect tests from folder xpect-pending and for all bundles inheriting from <literal>/tests/pom.xml</literal> all unit tests ending in <literal>* Pending</literal>. This profile is deactivated by default.</simpara>
-<simpara>A special jenkins-job - N4JS-IDE_nightly_bugreports_pending - is configured to run the pending tests and render an overview und history to compare issues over time. Due to internal Jenkins structures this build always marked failed, even though the maven-build succeeds successfully.</simpara>
-<simpara>Relevant additional information can be found in</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Jenkins job for pending cases: <link xl:href="http://build-master:8080/view/N4JS/job/N4JS-IDE_nightly_bugreports_pending/">http://build-master:8080/view/N4JS/job/N4JS-IDE_nightly_bugreports_pending/</link></simpara>
-</listitem>
-<listitem>
-<simpara>Testmatrix <link xl:href="https://docs.google.com/a/numberfour.eu/spreadsheets/d/1Blo58cRwIWemaiBNSnOtsQ8U7b3FoodX3yEs7oJKIg0/">https://docs.google.com/a/numberfour.eu/spreadsheets/d/1Blo58cRwIWemaiBNSnOtsQ8U7b3FoodX3yEs7oJKIg0/</link></simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="xpect-lint-tests">
-<title>Xpect Lint Tests</title>
-<figure xml:id="sec:XPECT_Lint_Tests">
-<title>Xpect Lint</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/15_tests/images/diag_XpectLint.svg"/>
-</imageobject>
-<textobject><phrase>diag XpectLint</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The test transpiles the provided n4js resource and checks the generated code. This is achieved using the Javascript linter JSHint.</simpara>
-<simpara>After transpiling the provided n4js resource the LintXpectMethod combines the generated code with the jshint code into a script. It calls the JSHint validation function and returns the linting result as a json object. The error results are displayed in the console. The script is executed using the <literal>Engine</literal> class. (<link linkend="sec:Design">Design</link>)</simpara>
-<simpara>For the linting process an adapted configuration for JSHint is used. For the needs of N4JS the linter is configured to recognise N4JS specific globals. Details about the error codes can be found at the <link xl:href="https://github.com/jshint/jshint/blob/2444a0463e1a99d46e4afa50ed934c317265529d/src/messages.js">jshint repository</link>.</simpara>
-<simpara>The following warnings are explicitly enabled/disabled:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis role="strong">W069</emphasis>: [’a’] is better written in dot notation <emphasis role="strong">DISABLED</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">W033</emphasis>: Missing semicolon <emphasis role="strong">ENABLED</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">W014</emphasis>: Bad line breaking before ’a’. <emphasis role="strong">DISABLED</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">W032</emphasis>: Uneccesarry semicolon <emphasis role="strong">ENABLED</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">W080</emphasis>: It’s not necessary to initialize ’a’ to ’undefined’. <emphasis role="strong">ENABLED</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">W078</emphasis>: Setter is defined without getter. <emphasis role="strong">DISABLED</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara>ES6 related warnings are <emphasis role="strong">disabled</emphasis> using the ’esnext’ option: <emphasis role="strong">W117</emphasis>: Symbol is not defined. <emphasis role="strong">DISABLED</emphasis> <emphasis role="strong">W104</emphasis>: ’yield’ is only available in ES6 <emphasis role="strong">DISABLED</emphasis> <emphasis role="strong">W117</emphasis>: Promise is not defined <emphasis role="strong">DISABLED</emphasis> <emphasis role="strong">W119</emphasis>: function* is only available in ES6 <emphasis role="strong">DISABLED</emphasis></simpara>
-</listitem>
-</itemizedlist>
-<simpara>The xpect lint test only applies if the provided resource passes the n4js compiler.</simpara>
-<simpara>The xpect method lintFails can be used to create negative tests. All linting issues discovered during the development of the xpect plugin have there own negative test to keep track of their existence.</simpara>
-<simpara>Additional information:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>JSHint: <link xl:href="http://jshint.com/docs/">http://jshint.com/docs/</link></simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-<section xml:id="xpect-proposal-tests" role="language-n4js">
-<title>Xpect Proposal Tests</title>
-<simpara>Proposal tests are all tests which verify the existence and application of completion proposals, created by content assist, quick fixes etc.</simpara>
-<simpara>The key attributes of a proposal (cf <literal>ConfigurableCompletionProposal</literal>) are:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>displayString</simpara>
-</entry>
-<entry>
-<simpara>the string displayed in the proposal list</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>replacementString</simpara>
-</entry>
-<entry>
-<simpara>simple variant of which is to be added to document, not necessarily the whole replacement (as this may affect several locations and even user interaction)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>In the tests, a <emphasis>proposal is identified by a string contained in the displayString</emphasis>. If several proposal match, test will fail (have to rewrite test setup or proposal identifier to be longer). Proposal identifier should be as short as possible (to make test robust), but not too short (to make test readable).</simpara>
-<simpara>The following proposal tests are defined:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>contentAssist <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo></mrow></math> List <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>]</mo></mrow></math></simpara>
-</entry>
-<entry>
-<simpara>verifies proposals created by content assist</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>quickFix <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo></mrow></math> List <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>]</mo></mrow></math></simpara>
-</entry>
-<entry>
-<simpara>verifies proposals created by quick fixes. Cursor position is relevant, that’s handled by the framework. We only create tests with cursor position – fixes applied via the problem view should work similarly, but without final cursor position.</simpara>
-<simpara>If no error is found at given position, test will fail (with appropriate error message!). In call cases of apply, the issue must be resolved. Usually, fixing an issue may leave the file invalid as other issues still exists, or because by fixing one issue others may be introduced (which may happen often as we try to avoid consequential errors in validation). For some special cases, quickFix tests support special features, see below.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Not tested in this context: Verify proposal description, as these tests would be rather hard to maintain and the descriptions are often computed asynchronously.</simpara>
-<section xml:id="sec:Validation_vs__Non_Validation">
-<title>Validation vs. Non-Validation</title>
-<simpara>We expect proposal tests to be applied on non-valid test files, and usually file is also broken after a proposal has been applied. Thus, the test-suite must not fail if the file is not valid.</simpara>
-</section>
-<section xml:id="sec:General_Proposal_Test_Features">
-<title>General Proposal Test Features</title>
-<section xml:id="sec:Test_Variables">
-<title>Test Variables</title>
-<simpara>Often, list of proposals are similar for different tests (which define different scenarios in which the proposals should be generated). For that reason, variables can be defined in the test set up:</simpara>
-<simpara>In the Xpect-Setup there is now a special <literal>Config</literal> component where specific switches are accessible. For instance the timeout switch for content assist can be modified:</simpara>
-<screen>/* XPECT_SETUP org.eclipse.n4js.tests.N4JSNotValidatingXpectPluginUITest
- ...
- Config {
- content_assist_timeout = 1000
- ...
- }
- ...
-*/</screen>
-<simpara>Note: There should only be one <literal>Config</literal> component per Xpect-Setup.</simpara>
-<simpara>Variables are introduced via the <literal>VarDef</literal> component. It takes a string argument as the variable name on construction. Inside the body one add <literal>MemberLists</literal> and <literal>StringLists</literal> arguments. Variable definitions may appear in <literal>Config</literal> bodies or in the Xpect-Setup.</simpara>
-<screen>VarDef "objectProposals" {
- ...
-}</screen>
-<simpara>Define variables with expression: A simple selector is given with the <literal>MemberList</literal> component. These components take three <literal>String</literal> arguments in the constructor. The first one is a typename. The second one is the feature selector, e.g. <literal>methods</literal> , <literal>fields</literal> , …and the third one defines the visibility.</simpara>
-<screen>/* XPECT_SETUP
-VarDef "stringProposals" { MemberList "String" "methods" "public" {}}
-END_SETUP */</screen>
-<simpara>We have to define a filter later in Xtend/Java, e.g., <literal>getClassWithName( <emphasis>className</emphasis> ).filterType(<emphasis>methods</emphasis>).filterVisibility(<emphasis>accessodifier</emphasis>)…​</literal></simpara>
-<simpara>A variable is later referenced as follows:</simpara>
-<screen><$variable></screen>
-<simpara>Usage example:</simpara>
-<screen>// XPECT contentAssistList at 'a.<|>methodA' proposals --> <$stringProposals>, methodA2
-a.methodA</screen>
-</section>
-<section xml:id="sec:Location_and_Selection">
-<title>at – Location and Selection</title>
-<simpara>Tokens in expectation/setup:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal><|></literal> cursor position</simpara>
-</listitem>
-<listitem>
-<simpara><literal><[></literal> selection start → also defines cursor position</simpara>
-</listitem>
-<listitem>
-<simpara><literal><]></literal> selection end</simpara>
-</listitem>
-</itemizedlist>
-<simpara>All proposal tests have to specify a location via <literal>at</literal>, the location must contain the cursor position and may contain a selection. E.g.:</simpara>
-<screen>// XPECT contentAssistList at 'a.<|>methodA' apply 'methodA2' --> a.methodA2()<|>methodA
-// XPECT contentAssistList at 'a.<|><[>methodA<]>' apply 'methodA2' override --> a.methodA2()<|>
-a.methodA</screen>
-</section>
-<section xml:id="sec:Multi_Line_Expectations_in_Proposal_Tests">
-<title>Multi Line Expectations in Proposal Tests</title>
-<simpara>In multiline expectations, ignored lines can be marked with <literal><…​></literal>. This means that 0 to n lines may occur but are ignored for comparison.</simpara>
-<simpara>All multiline expectations are compared line-wise, with exact match except line delimiters (which are ignored as well)</simpara>
-</section>
-<section xml:id="sec:Timeout">
-<title>Timeout and Performance</title>
-<simpara>We define a default timeout for content assist tests. In set up, this timeout may be changed:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/* XPECT SETUP
-...
-content_assist_timeout = 2000ms
-...
-END_SETUP */</programlisting>
-<simpara>Performance is measured by measuring the runtime of tests, we should later setup performance measurements similar to the performance tests.</simpara>
-</section>
-</section>
-<section xml:id="proposals-verify-existence-of-proposals">
-<title>proposals – Verify Existence of Proposals</title>
-<simpara>In general, one could verify if certain proposals are present or not present, and in which order they are present. This is verified by the <literal>proposals</literal> argument.</simpara>
-<simpara>E.g.</simpara>
-<screen>// XPECT contentAssistList at 'a.<|>methodA' proposals --> <$stringProposals>, methodA2
-a.methodA</screen>
-<simpara>Additional flags:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Order modifier:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>unordered</simpara>
-</entry>
-<entry>
-<simpara>by default</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>ordered</simpara>
-</entry>
-<entry>
-<simpara>the given expectations have to have that order, between these expectations other proposals may be present (in case of contains)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-<listitem>
-<simpara>Subset modifier:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>exactly</simpara>
-</entry>
-<entry>
-<simpara>(default, maybe changed later) no other expectations as the given ones (usually <literal>contains</literal> is recommended).</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>contains</simpara>
-</entry>
-<entry>
-<simpara>at least the given expectations must be present, but others may be there as well.</simpara>
-<simpara>Using <emphasis>contains</emphasis> must be used with care since we match items by searching for a proposal which contains one of the expected strings as a substring. So if the only available proposal were ’methodA2’ and we would test if proposals contain ’methodA’, ’methodA2’ we would obtain a passing test.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>not</simpara>
-</entry>
-<entry>
-<simpara>any of the given proposals must be NOT be proposed</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Verify_displayed_string">
-<title>display – Verify displayed string</title>
-<simpara>We do not verify the text style. We only verify text:</simpara>
-<screen>// XPECT contentAssistList at 'a.<|>methodA' display 'methodA2' --> 'methodA2(): any - A'
-a.methodA</screen>
-<simpara>This kind of test should be only applied for few scenarios, because the long display tests are rather hard to maintain.</simpara>
-</section>
-<section xml:id="sec:Apply_Proposal">
-<title>apply – Apply Proposal</title>
-<simpara>Execution of proposal, the expectation describes the expected text result. The tests follow the naming convention of Ending in …Application.</simpara>
-<simpara>Additional flags:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>insertion mode</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>insert</simpara>
-</entry>
-<entry>
-<simpara>(default) Ctrl not pressed, proposal is inserted at given location</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>override</simpara>
-</entry>
-<entry>
-<simpara>Ctrl is pressed, proposal overrides selection.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-</itemizedlist>
-<simpara>Single line assumes change at line of initial cursor position:</simpara>
-<screen>// XPECT contentAssist at 'a.<|>methodA' apply 'methodA2' --> a.methodA2()methodA
-// XPECT contentAssist at 'a.<|>methodA' apply 'methodA2' insert --> a.methodA2()methodA
-// XPECT contentAssist at 'a.<|>methodA' apply 'methodA2' override --> a.methodA2()
-a.methodA</screen>
-<simpara>or</simpara>
-<screen>// XPECT quickFix at 'a.<|>method' apply 'methodA2' --> a.methodA2();
-a.methodTypo();</screen>
-<simpara>Multiline expectations describe changes to the whole. In order to match the expectation context information around the relevant places must be given. The format is similar to a unified diff with a special rule for inline-changes. The comparison works in a line-based mode. Each line in the expectation is prefixed with one character of ’+’, ’|’, ’-’ or ’ ’. Inserted lines are marked with + and removed lines with -. Lines marked with | denote changes in the line. Difference is placed inline inside of a pair of square brackets with a | separating the removal on the left and the addition on the right.</simpara>
-<screen>/* XPECT contentAssistList at 'a.me<|>thodA' apply 'methodA2' ---
-<...>
-import A from "a/b/c"
-<...>
-a.methodA2()<|>methodA
-<...>
---- */
-a.methodA</screen>
-<screen>/* XPECT contentAssistList at 'a.me<|>thodA' apply 'methodA2' ---
- import B from "p/b"
-+import A from "a/b/c"
-
- ...
- foo() {
-|a.[me|thodA2()]
- }
- ...
---- */
-a.methodA</screen>
-<section xml:id="resource-application-in-other-files">
-<title>resource – application in other files</title>
-<simpara>The resource parameter is available for the quickfix xpect method. It specifies the target resource of the quickfix. (e.g. change declaration of type in another file to quickfix an issue).</simpara>
-<screen>/* XPECT quickFix at 'sameVendor.protected<|>Method()' apply 'Declare member as public, @Internal' resource='../../otherProject/src/other_file.n4js' ---
-diff here
----
-*/</screen>
-<simpara>The syntax is similar to a normal multiline quickfix xpect test besides the addition of the resource parameter. The relative path points to a file in the same workspace as the test file. Note that the path refers to the folder structure specified in the XPECT SETUP header. It is relative to the folder the test file is contained in.<?asciidoc-br?>
-<?asciidoc-br?>
-The diff is between the specified resource before and after the application of the quickfix<?asciidoc-br?>
-<?asciidoc-br?>
-Note that the fileValid (<link linkend="fileValidVerify-validation-status">Verify Validation Status</link>) parameter is not applicable to an extern resource.</simpara>
-</section>
-</section>
-<section xml:id="sec:Content_Assist_Cycling">
-<title>kind – Content Assist Cycling</title>
-<simpara>We assume the default kind to be ’n4js’. It is possible to select a proposal kind in the test set up or via the argument <literal>kind</literal> in the test.</simpara>
-<simpara>Select kind in test setup:</simpara>
-<screen>/* XPECT_SETUP
-content_assist_kind = 'recommenders'
-END_SETUP */</screen>
-<simpara>Select kind in test:</simpara>
-<screen>// XPECT contentAssistList kind 'smart' at 'a.<|>methodA' display 'methodA2' --> 'methodA2(): any - A'
-a.methodA</screen>
-</section>
-<section xml:id="fileValidVerify-validation-status">
-<title>fileValid – Verify validation status</title>
-<simpara>In some cases, in particular in case of quick fix tests, the file should be valid after the proposal has been applied. This is added by an additional argument <literal>fileValid</literal>.</simpara>
-<simpara>E.g.,</simpara>
-<screen>// XPECT quickFix at 'a.<|>method' apply 'methodA2' fileValid --> a.<|>methodA2();
-a.methodTypo();</screen>
-</section>
-</section>
-<section xml:id="sec:Apply_Proposal_And_Execute_Tests" role="language-n4js">
-<title>Apply Proposal And Execute Tests</title>
-<simpara>If a proposal fixes all issues in a test file, the file could be executed. This is an important type of test, as this is what the user expects in the end. Besides, this type of test is very robust, as it does not depend on the concrete way how an issue is fixed. For quick fixes, these kind of tests are to be implemented!</simpara>
-<simpara>The following combined proposal and execute tests are provided:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>quickFixAndRun</simpara>
-</entry>
-<entry>
-<simpara>applies a quick fix, verifies that all issues are solved, and executes the file.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>These tests are basically execution tests, that is the expectation describes the expected output of the script.</simpara>
-<simpara>E.g.</simpara>
-<screen>// XPECT quickFixAndRun at 'a.<|>method' apply 'methodHelloWorld' --> Hello World
-a.methodTypo();</screen>
-<simpara>with <literal>methodHelloWorld</literal> printing <literal>’Hello World’</literal> to the console. The expected output can be multiline:</simpara>
-<screen>/* XPECT quickFixAndRun at 'a.<|>method' apply 'methodHelloWorld' ---
-Hello World
---- */
-a.methodTypo();</screen>
-</section>
-<section xml:id="sec:Organize_Imports_Test" role="language-n4js">
-<title>Organize Imports Test</title>
-<simpara>For testing organise imports a Plugin-UI test method is available. It operates in two modes. Either a successful application of organise imports is tested or the expected abortion is checked.</simpara>
-<section xml:id="organizeimports">
-<title>organizeImports</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Definition</simpara>
-</entry>
-<entry>
-<simpara>Multi line:</simpara>
-<screen>/* XPECT organizeImports ---
-~Failure given by line-syntax starting with two characters:~
-+ additional line
-| line with inplace[removed part|added part]
-+ removed line
- unchanged line
---- */
-// XPECT warnings --> "The import of A is unused." at "A"
-import A from "a/a1/A"
-...
-}</screen>
-<simpara>Single line:</simpara>
-<screen>// XPECT organizeImports ambiguous '~Failure String of Exception~'-->
-}</screen>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Provided by</simpara>
-</entry>
-<entry>
-<simpara><literal>OrganizeImportXpectMethod</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Description</simpara>
-</entry>
-<entry>
-<simpara>Checks that the resulting source-file differs in the described way. The Multiline variant checks the result of a successful application of organise import to the file. All errors and warnings prior to organising imports must be marked as the appropriate XPECT-error or warning.</simpara>
-<simpara>The single-line notation checks the failure of an fully automatic reorganisation of the imports due to some reason. The reason is verified to be the given string after the <literal>ambiguous</literal> keyword. The expectation side (right of <literal>-→</literal>) is empty.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<screen>/* XPECT_SETUP org.eclipse.n4js.tests.N4JSXpectPluginUITest
- Workspace {
- Project "P1" {
- Folder "src" {
- Folder "a" { Folder "a1" { File "A.n4js" { from="../../a/a1/A.n4js" } }
- Folder "c" { ThisFile {} } } }
- File "package.json" { from="package_p1.json" } } }
- END_SETUP
-*/
-
-/* XPECT organizeImports ---
-
- | import [A from "a/a1/A"|]
- | [import|] AR from "a/a1/A"
- export public role BRole with AR {
- }
---- */
-// XPECT warnings --> "The import of A is unused." at "A"
-import A from "a/a1/A"
-import AR from "a/a1/A"
-
-// XPECT noerrors --> "Couldn't resolve reference to Type 'AR'."
-export public role BRole with AR {
-}</screen>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-</section>
-<section xml:id="sec:Access_Control_Test" role="language-n4js">
-<title>Access Control Test</title>
-<simpara>Access control refers to the decision whether or not a member or a top level element is accessible for a client. In this context, access refers to reading, writing, and calling a member or a top level function, and to overriding inherited members in classes and interfaces. In N4JS, access is controlled via modifiers at the type and at the member level. Due to the large number of such modifiers and the large number of different scenarios for access control, manually written tests can only cover a small number of actual scenarios. An automatic test generator helps to increase the test coverage for access control.</simpara>
-<simpara>The test generator loads test scenarios from a CSV table that also contains the expected results of each test case and then generates N4JS projects and code for each test case, compiles them using the headless compiler, and compares the compilation results to the expectations from the CSV table. Note that the test generator does not generate test cases that check access control for top level functions and variables.</simpara>
-<section xml:id="test-scenarios">
-<title>Test Scenarios</title>
-<simpara>Each test scenario consists of a scenario specifier (one of <literal>Extends</literal> , <literal>Implements</literal> , <literal>References</literal> ), a supplier and a client (each of which can be a class, and abstract class, an interface, or an interface with default implementations of its getters, setters, and methods). Thereby, the client attempts to access a member of the supplier either by reading, writing, or calling it or by overriding it in the case of an <literal>Extends</literal> or <literal>Implements</literal> scenario. Furthermore, each test cases specifies the location of the client in relation to the location of the supplier, e.g., whether the client is in the same module, or whether it is in the same project (but not the same module), and so forth. Finally, a test case must specify the access control modifiers of the supplier type and the member that is being accessed by the client, whether that member is static or not, and, lastly, the type of access that is being attempted.</simpara>
-</section>
-<section xml:id="n4js-code-generator">
-<title>N4JS Code Generator</title>
-<simpara>The test generator needs to generate N4JS projects and modules that implement a particular test case. For this purpose, it uses a simple code generator, available in the package <literal>org.eclipse.n4js.tests.codegen</literal>. The classes in that package allow specifying N4JS projects, modules, classes, and members in Java code and to generate the required artifacts as files at a given location.</simpara>
-</section>
-<section xml:id="xtext-issue-matcher">
-<title>Xtext Issue Matcher</title>
-<simpara>To match the test expectations from the CSV file against the issues generated by the compiler, the test generator uses a small library of issue matchers, available in the package <literal>org.eclipse.n4js.tests.issues</literal>. The classes in that package make it easy to specify expectations against Xtext issues programmatically and to evaluate these expectations against a specific set of Xtext issues. Mismatches, that is, unexpected issues as well as unmatched expectations, are explained textually. These explanations are then shown in the failure notifications of the test case generator.</simpara>
-<simpara>The test expectations allow for FIXME annotations in the CSV table to express cases where an access control error has been found, but hasn’t been fixed yet. Such expectations lead to inverted expectations against the generated issues: For example, if a test expects an attempted access to fail with an error, but the validation rules allow the access regardless, then a FIXME annotation at the test will invert the actual expectation: Where previously an error was expected, there must now be no error at all. Then, once the validation rules have been adjusted and the error occurs as expected, the FIXME test case will fail until the FIXME annotation has been removed. Therefore, the issue expectation matchers can be inverted and adjust their behavior accordingly.</simpara>
-</section>
-</section>
-<section xml:id="sec:Smoke_Tests" role="language-n4js">
-<title>Smoke Tests</title>
-<simpara>Smoke tests are useful to ensure the robustness of the IDE. They aim at revealing potential exceptions that may surface to the end user in the IDE or in a headless compile run. Therefore, different permutations of a given input document are fed into processing components such as the validator or the type system. No exceptions may be thrown from these components.</simpara>
-<simpara>Since smoke tests are longrunning, it is not desired to execute them with each Maven run. That’s why the naming convention <literal>* Smoketest</literal> was choosen. It will not be matched by the naming pattern for normal JUnit tests during a maven run.</simpara>
-<simpara>The smoke tests are generally created by using the (valid or invalid) input of existing test cases. Therefore, the a command line argument <literal>-DSmokeTestWriter=true</literal> may be passed to the VM that executes a test. All input documents that are processed by a <literal>ParseHelper<Script></literal> will be written to a new test method on the console. The result can be merged manually into the <literal>GeneraredSmoketest</literal>.</simpara>
-<section xml:id="how-to-handle-smoke-test-errors">
-<title>How to handle smoke test errors?</title>
-<simpara>If a smoke test fails, the concrete input should be extracted into a dedicated error test case. The existing classes like <literal>scoping.ErrorTest</literal> should be used to add the broken input document and create fast running cases for them. For that purpose, the <literal>ExceptionAnalyzer</literal> can be used. Such a test case will usually look like this:</simpara>
-<screen>@Test
-def void testNoNPE_03() {
- val script = `` '
- var target = {
- s: "hello",
- set x
- `` '.parse
- analyser.analyse(script, "script", "script")
-}</screen>
-</section>
-<section xml:id="smoketester-and-exceptionanalyzer">
-<title>SmokeTester and ExceptionAnalyzer</title>
-<simpara>The components that are used to implemement the smoke tests are the <literal>SmokeTester</literal> and the <literal>ExceptionAnalyzer</literal>. The smoke tester performs the permutation of the characters from the input model whereas the analyzer does the heavy lifting of passing the parsed model to various components such as the type system or the validation. Both utilities can be used to add either new smoke test documents or to check for the robustness of an implementation. It’s espeically useful to use the ExceptionAnalyzer in conjunction with existing test suites like the <literal>LibraryParsingTestSuite</literal> since it can be used instead of the other utilities like the <literal>PositiveAnalyzer</literal> or the <literal>NegativeAnalyzer</literal>.</simpara>
-</section>
-</section>
-<section xml:id="sec:UI_Tests_with_SWTBot" role="language-n4js">
-<title>UI Tests with SWTBot</title>
-<simpara>For testing functionality from the end-user perspective we use UI tests based on SWTBot <link xl:href="http://eclipse.org/swtbot/">http://eclipse.org/swtbot/</link>.</simpara>
-<simpara>Since UI tests are usually rather fragile, it was decided to keep the number of these tests as low as possible. The main purpose of these tests is to ensure that the most fundamental IDE functionality is working properly, e.g. creating an N4JS project, creating a new N4JS file, running N4JS code in node.js.</simpara>
-<simpara>The tests have a number of SWTBot dependencies. For details, please refer to the latest target platform definition file.</simpara>
-<section xml:id="writing-swtbot-tests">
-<title>Writing SWTBot Tests</title>
-<simpara>The implementation is contained in bundle <literal>org.eclipse.swtbot.tests</literal>. Writing SWTBot tests is straightforward; see source code of <literal>AbstractSwtBotTest</literal> for usage and examples.</simpara>
-<simpara>Some hints:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Many methods of the SWTBot framework already include assertions. For example, the method <literal># menu(String)</literal> to find a particular menu or menu item will assert that the item was found and otherwise throw an exception. Therefore, it is safe to write code like:</simpara>
-<screen>bot.menu("File").menu("New").menu("Project...").click();</screen>
-</listitem>
-<listitem>
-<simpara>It is usually considered bad practice to use sleep delays in UI tests. Instead, wait for the element to appear using methods such as <link xl:href="http://download.eclipse.org/technology/swtbot/helios/dev-build/apidocs/org/eclipse/swtbot/swt/finder/SWTBot.html#waitUntil">http://download.eclipse.org/technology/swtbot/helios/dev-build/apidocs/org/eclipse/swtbot/swt/finder/SWTBot.html#waitUntil</link> or <link xl:href="http://download.eclipse.org/technology/swtbot/helios/dev-build/apidocs/org/eclipse/swtbot/swt/finder/SWTBot.html#waitWhile">http://download.eclipse.org/technology/swtbot/helios/dev-build/apidocs/org/eclipse/swtbot/swt/finder/SWTBot.html#waitWhile</link>.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="running-swtbot-tests">
-<title>Running SWTBot Tests</title>
-<simpara>To run the tests locally in Eclipse just right-click the bundle and select <literal>Run As > SWTBot Test</literal> . To run them locally via maven simply start a normal maven build, no additional command line arguments, etc. required.</simpara>
-<simpara>To run remotely in a Jenkins build: on Windows the build must be executed with a logged-in user; on Linux Xvfb and a window manager are required. The recommended window manager is metacity. More information can be found here: <link xl:href="http://wiki.eclipse.org/SWTBot/Automate_test_execution">http://wiki.eclipse.org/SWTBot/Automate_test_execution</link>.</simpara>
-<simpara>To use metacity, add the following pre-build shell command to the Jenkins build configuration:</simpara>
-<programlisting language="bash" linenumbering="unnumbered">sleep 5; metacity --replace --sm-disable &</programlisting>
-<simpara>The sleep is required because metacity depends on Xvfb to be fully initialized, which might take a moment on slower build nodes. The following Jenkins console log shows the expected output when starting Xvfb and metacitiy:</simpara>
-<programlisting language="bash" linenumbering="unnumbered">Xvfb starting$ Xvfb :1 -screen 0 1024x768x24 -fbdir /var/lib/build/2014-09-05_10-36-343337290231975947044xvfb
-[N4JS-IDE_Oliver] $ /bin/sh -xe /tmp/hudson4475531813520593700.sh
-+ sleep 5
-+ metacity --replace --sm-disable
-Xlib: extension "RANDR" missing on display ":1.0".
-Window manager warning: 0 stored in GConf key /desktop/gnome/peripherals/mouse/cursor_size is out of range 1 to 128
-Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information
-Parsing POMs
-...</programlisting>
-<simpara>The warnings and error messages in the above log are expected and are considered unharmful (cf. discussion with Jörg Baldzer).</simpara>
-</section>
-</section>
-<section xml:id="sec:Debugging_UI_Tests">
-<title>Debugging UI Tests</title>
-<simpara>In rare cases UI Tests behave differently depending on the underlying OS und the power of the test machine. Missing user interaction on the build-server often results in waiting processes which in turn get a timeout request from the driving unit-testing-framework. To investigate the UI state on the build node a X11 connection needs to established.</simpara>
-<section xml:id="sec:Connecting_to_the_X_server_on_the_build_node">
-<title>Connecting to the X-server on the build-node</title>
-<simpara>First a vnc server needs to be started on the build-node. This is done via <literal>x11vnc -display :1 -shared > /x11vnc.log 2>&1 &</literal> as a pre-build shellscript-step in Jenkins.</simpara>
-<simpara>You can narrow down the build to run on a specific node in Jenkins if a repeatable environment is required otherwise the current build-node is listed in the overview page. For security reasons the connection needs to be tunneld through an ssh login:</simpara>
-<programlisting language="bash" linenumbering="unnumbered">ssh -l viewer -L 5900:localhost:5900 build-linux-25 ’x11vnc -localhost -display :1</programlisting>
-<simpara>Here we are using the mating <literal>build-linux-25</literal> with the generic user/password ’viewer’ to start the program <literal>x11vnc</literal>. For the actual display number – <literal>:1</literal> in this case – you can refer to the console output. The command above tunnels the default vnc port 5900. You can now connect on <literal>localhost</literal> with a vnc client. If the user is not available, the <literal>x11vnc</literal> program not installed or in case of other issues, ask the build-and-release team.</simpara>
-<simpara>To display the screen you can use any arbitrary vnc-client (on mac there is screen sharing, in theory just opened from the command line by hitting <literal>open vnc://viewer:viewer@localhost:5900</literal>). One working client is ’chicken of the vnc’ <link xl:href="http://sourceforge.net/projects/cotvnc/">http://sourceforge.net/projects/cotvnc/</link></simpara>
-</section>
-<section xml:id="sec:Tools_to_investigate_the_java_stack">
-<title>Tools to investigate the java-stack</title>
-<simpara>Unix and Java come with some useful programs for investigations. The following tools may need some advanced rights to see processes from other users.</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>htop</literal> enhanced top to see all currently running processes</simpara>
-</listitem>
-<listitem>
-<simpara><literal>jps</literal> list running java processes</simpara>
-</listitem>
-<listitem>
-<simpara><literal>jstack</literal> investigate running java process</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_ui-concepts">
-<title>UI Concepts</title>
-<warning>
-<simpara>Parts of this chapter may be outdated.</simpara>
-</warning>
-<section xml:id="sec:User_Interface_Concepts" role="language-n4js">
-<title>User Interface Concepts</title>
-<section xml:id="sec:Eclipse_UI_Concepts">
-<title>Eclipse UI Concepts</title>
-<simpara>The following list gives an overview of Eclipse specific UI concepts and which classes are used for implementation.</simpara>
-<section xml:id="sec:Label_Provider">
-<title>Label Provider</title>
-<simpara>Also provides decorations for icons and text labels.</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Example</simpara>
-</entry>
-<entry>
-<simpara>The representation of objects in the outline view or in search results.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara><literal>o.e.jface.viewers.ILabelProvider</literal> → without styes</simpara>
-</listitem>
-<listitem>
-<simpara><literal>o.e.jface.viewers.DelegatingStyledCellLabelProvider.IStyledLabelProvider</literal> → with styles Drawback: Depends on Image rather than ImageDescriptor (see below)</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara><literal>Declarative API</literal> via reflective, polymorphic dispatching. <literal>org.eclipse.xtext.ui.label.AbstractLabelProvider</literal></simpara>
-</listitem>
-<listitem>
-<simpara>Allows to work with ImageDescriptors (non-ui-thread, can be composed), but cumbersome</simpara>
-</listitem>
-<listitem>
-<simpara>DefaultLabelProvider will be used everywhere (outline etc.), returns the <literal>name</literal> (via reflection). You could bind specific label providers.</simpara>
-</listitem>
-<listitem>
-<simpara>DescriptionLabelProvider provides labels for objects from the Xtext index used by <literal>open model element</literal> , <literal>find references</literal> – the later is already customized)</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practices</simpara>
-</entry>
-<entry>
-<simpara>Labels are often use-case specific, so a single label provider is not always useful Therefore, in Xtext are different label providers for different use cases. Use cases are defined and enumerated (see <literal>DefaultUiModule.configure*Label*</literal>).
-+
-Often labels could be easier created where they are needed instead of using a label provider (even for things like OutlineView). (LabelProvider are maybe over-engineered). (Note: default label provider has dependencies to SWT, because it uses images, which are often not needed; also they are only called with an object and no further configuration).
-+
-Images:
-+</simpara>
-<itemizedlist>
-<listitem>
-<simpara>DeclarativeLabelProvider: text and image (String: path relative to icons folder; or: ImageDescriptor, or Image), put it into folder (needs to be called <literal>icons</literal> , otherwise bind another name)</simpara>
-</listitem>
-<listitem>
-<simpara>better use AbstractLabelProvider and use EMF concepts (easier to debug and handle)</simpara>
-</listitem>
-<listitem>
-<simpara>image format and size: sub-folders with 32, 12, 16, 24, etc. (look which sizes are needed); in about view maybe bigger; png (supports transparency)</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Markers">
-<title>Markers</title>
-<blockquote>
-<attribution>
-Eclispe Help
-</attribution>
-<simpara>Markers are objects that may be associated with Workbench resources. There are many uses of markers in the Workbench…​
-Markers are shown in a marker view (Tasks, Problems or Bookmark view) or on the marker bar in the editor area.</simpara>
-</blockquote>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Tasks, Problems, Bookmarks, Breakpoints, Trace information</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara><literal>org.eclipse.core.resources.IMarker</literal> and <literal>IResource.findMarkers</literal>
-+</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Marker types registered via extension point (basically String). A marker is more or less a Map of String → String with some meta information, e.g. the resource location in WS, line numbers, type</simpara>
-</listitem>
-<listitem>
-<simpara>Markers are very efficient (e.g., find markers of a certain type), cf Xtext Specifics</simpara>
-</listitem>
-<listitem>
-<simpara>For validation, some new marker types are already registered.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext</simpara>
-</entry>
-<entry>
-<simpara>(2.6)
-+</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Todo-Markers are created during build, task list is populated by these markers.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>org.eclipse.xtext.tasks.ITaskFinder</literal> (and default implementation is bound by default, can be replaced with custom implementation)</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practices</simpara>
-</entry>
-<entry>
-<simpara>In Xtend, markers are used to trace from original file to generated file. They are hidden (and not displayed), so in general markers can be used for non-UI-problems as well (but only available in Eclipse of course) clean up markers: no general solution, often managed by some (single) life-cycle aware class (e.g., Builder)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Commands__Toolbar_and_Menus">
-<title>Commands, Toolbar and Menus</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Organize Imports,</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>use Commands + Handlers instead of Actions (or ActionDelegates etc.)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>uses commands and handlers</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<simpara><emphasis role="strong">Use commands and handlers</emphasis> -
-handler usually only delegates to real thing (that is, retrieve parameters from context and call the real thing)<?asciidoc-br?>
-<emphasis role="strong">Register in pluginxml</emphasis> via ExecutableExtensionFactory to be able to use injection (also pre-generatd, e.g.:</simpara>
-<programlisting language="xml" linenumbering="unnumbered"> <handler class="org.eclipse.n4js.ui.N4JSExecutableExtensionFactory:org.eclipse.xtext.ui.editor.handler.ValidateActionHandler"
- commandId="org.eclipse.n4js.N4JS.validate"></programlisting>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><emphasis role="strong">Undo</emphasis>: use TextEdit and MultiTextEdit (composed)<?asciidoc-br?>
-otherwise very low level</simpara>
-</section>
-<section xml:id="sec:Content_Assist">
-<title>Content Assist</title>
-<blockquote>
-<attribution>
-Eclipse Help
-</attribution>
-<simpara>Content assist allows you to provide context sensitive content completion upon user request. Popup windows (infopops) are used to propose possible text choices to complete a phrase. The user can select these choices for insertion in the text. Content assist also supports contextual infopops for providing the user with information that is related to the current position in the document.</simpara>
-</blockquote>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Risk</simpara>
-</entry>
-<entry>
-<simpara>Always needs longer than anticipated.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>complete name of function in function call, complete keywords</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>IContentAssistant wraps the widget,</simpara>
-</listitem>
-<listitem>
-<simpara>IContentProposalProvider computes the (array of) CompletionProposal (quite cumbersome!).</simpara>
-</listitem>
-<listitem>
-<simpara>Many extension interfaces that provide valuable UI features.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>ConfigurableCompletionProposal implements the currently defined extension interfaces, provides getters to modify the proposal after the fact.</simpara>
-</listitem>
-<listitem>
-<simpara>Context: The ContentAssistContext is provided by the framework according to the current cursor position in the document (cf. <literal>ContentAssisParser</literal>), semantic context (semantic element) computed with best match strategy (worst case you get the root element). Multiple contexts may be valid at the very same cursor position since the replace region may be different for different proposals.</simpara>
-</listitem>
-<listitem>
-<simpara>Various abstracts above the JFace stuff are available in Xtext, some of the <literal>over the top</literal> , others quite handy.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practices</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>List of follow elements can be supposed to be complete, no need to figure out them with regular expressions etc.</simpara>
-</listitem>
-<listitem>
-<simpara>in rare cases it is necessary to <literal>manually</literal> scan the text context, e.g. to get the variable name based on the variable type. → we will provider a utility class for that using regex. NEVER search on the text with simple string methods.</simpara>
-</listitem>
-<listitem>
-<simpara>In N4JSProposalProvider, override pre-generated methods (see <literal>AbstractN4JSProposalProvider</literal>) – do not overload (with concrete semantic element)</simpara>
-</listitem>
-<listitem>
-<simpara>how to implement complete-methods:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>inspect context, examine current semantic element provide elements from scope or hard coded proposal: see <xref linkend="sec:Proposals"/></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Quick_Fixes">
-<title>Quick Fixes</title>
-<blockquote>
-<attribution>
-Eclipse Help
-</attribution>
-<simpara>Users can select a problem marker and choose a Quick Fix from a popup containing the list of supplied fixes contributed for the marker.</simpara>
-</blockquote>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Add Import, Add Override Annotation</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>Based on ICompletionProposal (powerful)
-+</simpara>
-<itemizedlist>
-<listitem>
-<simpara>QuickFixes are registered to marker (marker attribute: is fixable or not – this attribute is a guess only, there does not need to be a quick fix)</simpara>
-</listitem>
-<listitem>
-<simpara>MarkerResolutionGenerator (can also be used to fix several markers at once)</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>Based on ISematicModification (seemingly powerful but in fact weak) and IModification (less weak, but still very weak compared to ICompletionProposal) – only creates DocumentChanges.
-+
-Declarativ API that links to issue codes via annotations on 'fix' methods in AbstractDeclarativeQuickfixProvider.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practices</simpara>
-</entry>
-<entry>
-<simpara>ICompletionProposal vs. DocumentChanges, ICompletionProposal is much more powerful. IModifications can also provide semantic changes, but not really recommended
-+</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Associated to isses via IssueCodes, @Fix similar to @Check API – only less powerful Xtext abstraction (no ICompletionProposal)</simpara>
-</listitem>
-<listitem>
-<simpara>use issue data to provide hints for fix labels (which should be fast!) or solution strategies (but only strings) → do not compute the label for the fix from the model!</simpara>
-</listitem>
-<listitem>
-<simpara>share code between checks and fixes → no built-in pattern, come up with utility methods (maybe define conventions)</simpara>
-</listitem>
-<listitem>
-<simpara>maybe Sebastian can add a solution that more information is available via @Fix-approach</simpara>
-</listitem>
-<listitem>
-<simpara>no order of quickfixes (sorted by name and priority, latter is not provided by default)</simpara>
-</listitem>
-<listitem>
-<simpara>there can be several @Fix for a single issue code, or pass arbitrary number of resolution to the acceptor</simpara>
-</listitem>
-<listitem>
-<simpara>for most cases simple Xtext quick fix api is good enough (e.g. all Xtend quick fixes use that)
-+
-→ Xtext feature request: solve multiple markers at a time (possible to do that right now: bind custom <literal>XtextQuickAssistProcessor</literal>, override <literal>MarkerResolutionGenerator.getAdaptedResolutions(List<IssueResolution></literal>) – return a WorkbenchMarkerResolution)</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Quick_Assist">
-<title>Quick Assist</title>
-<blockquote>
-<simpara>"Quick assists perform local code transformations. They are invoked on a selection or a single cursor in the Java editor and use the same shortcut as quick fixes (Ctrl+1), but quick assist are usually hidden when an error is around. To show them even with errors present on the same line, press Ctrl+1 a second time." (Eclipse Help)</simpara>
-</blockquote>
-<simpara><literal>like a quickfix without a problem</literal></simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Add/remove inferred types</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>Takes cursor position</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext</simpara>
-</entry>
-<entry>
-<simpara>no Xtext support, e.g. no default implementation (XtextQuickAssistProcessor is a quick fix provider, has nothing to do with QuickAssist) but: XtextQuickAssistProcessor, override canAssist, override computeQuickAssistProposals</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Clean_Up_Actions">
-<title>Clean Up Actions</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Remove unused local vars, sort members</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>None, JDT specific (see ICleanUp)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>None</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<simpara>Monkey sees - Monkey does (look at JDT), In the end a it’s a CompositeRefactoring, which is a CompletionProposal</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Save_Actions">
-<title>Save Actions</title>
-<simpara>Similar to clean up actions but performed on save</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Format on save, Organize imports on save</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>None, JDT specific (see IPostSaveListener)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>None</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<simpara>XtextDocumentProvider.doSaveDocument (maybe better solutions in the future ;-) )</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Auto_Edit">
-<title>Auto Edit</title>
-<simpara>Auto edit is about closing braces that just have been typed, adding indentation after a line break the code snippet <literal>if (true)</literal> so basically it should be unobtrusive typing aids.</simpara>
-<simpara>By default, restore model structure when editing (guide the user to proper text formatting, help the parser). Should not be used for other purposes in order to not hinder the user’s flow of editing.</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>( → ( <cursor> )</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>org.eclipse.jface.text.IAutoEditStrategy</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>org.eclipse.xtext.ui.editor.autoedit.AbstractEditStrategy, some utility methods + implements VerifyKeyListener. May use the ISourceViewer via implements ISourceViewerAware</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practices</simpara>
-</entry>
-<entry>
-<simpara>Keep it as it is.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Fun example but not useful in practice cf. <link xl:href="https://code.google.com/a/eclipselabs.org/p/xtext-forms-integration/source/browse/trunk/plugins/org.eclipse.xtext.example.domainmodel.ui/src/org/eclipse/xtext/example/ui/autoedit/FantasticAutoEditStrategy.java?r=19">FantasticAutoEditStrategy</link></simpara>
-</section>
-<section xml:id="sec:Template_Proposals">
-<title>Template Proposals</title>
-<simpara>More sophisticated edit utils that are invoked by means of content assist.</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>sysout → System.out.println(<literal><cursor></literal> );</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>Part of the completion proposal API, e.g. ICompletionProposal</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>org.eclipse.xtext.ui.editor.contentassist.ITemplateProposalProvider, template contexts along the grammar rules by default, need to be stripped down to become usable.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<simpara>ship some: create them manually in workbench, export them as XML, fix XML file (add IDs, in Xtext documentation), put XML file in folder <literal>templates</literal> in UI plugin where propose a certain proposal: customize XtextTemplateContextTypeRegistry (bind subclass, override register context types) – by default too many context types are registered placeholders inside templates specific to Xtext – RTFM</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Outline_View___Quick_Outline">
-<title>Outline View / Quick Outline</title>
-<simpara>Structural represenation of the file contents (usually with different filter and sorting strategies).</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Outline View (but not Navigator nor package explorer), Quick Outline (in Xtext: same provider)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>org.eclipse.ui.views.contentoutline.IContentOutlinePage</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>Lazy tree creation, syncing via EObject ranges, thread save access to the EObject from nodes. Declarative API to create the tree contents. org.eclipse.xtext.ui.editor.outline.impl.DefaultOutlineTreeProvider
-+
-allow actions on outline nodes (e.g., goto referenced file in <literal>import</literal> of outline)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>Produced from semantic model, tree structure of outline nodes</simpara>
-<itemizedlist>
-<listitem>
-<simpara>show tree based on TypeModel, maybe filter out elements w/o SyntaxElements (with type model, this should be rather cheap!)</simpara>
-</listitem>
-<listitem>
-<simpara>use icons and styled labels (first user impression!)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>May run in the background (BackgroundOutlineTreeProvider)</simpara>
-</listitem>
-<listitem>
-<simpara>done lazily</simpara>
-</listitem>
-<listitem>
-<simpara>workflow: reconceiler: outline is a model listener</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Helpful tools for icons in outline view:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><link xl:href="http://marketplace.eclipse.org/content/eclipse-icon-archive-tool">Eclipse view</link> to show available Eclipse icons (that are of course licenced under EPL) with possibility to export them (<link xl:href="http://bwgz-org.googlecode.com/files/EclipseIconArchiveTool-1.pdf">documentation</link>)</simpara>
-</listitem>
-<listitem>
-<simpara>overview of Eclipse icons: <link xl:href="http://eclipse-icons.i24.cc/">http://eclipse-icons.i24.cc/</link></simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Navigator__Package_Explorer__Project_Explorer">
-<title>Navigator, Package Explorer, Project Explorer</title>
-<simpara>three <literal>explorers</literal> , Navigator <literal>latest</literal> and most extensible one</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Best Practices</simpara>
-</entry>
-<entry>
-<simpara>use Navigator only! (RTFM, nothing specific to Xtext yet)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>cf. <link xl:href="http://projects.eclipse.org/projects/technology.handly">http://projects.eclipse.org/projects/technology.handly</link> <literal>read index and show it in the navigator</literal></simpara>
-</section>
-<section xml:id="sec:Hyperlinking_and_Navigation">
-<title>Hyperlinking and Navigation</title>
-<simpara>Linking (propose multiple linking targets, e.g. goto declaration or goto implementation when CTRL (or other modifier) + Left Mouse Click on method when receiver type is interface - show all available implementations)</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Go to declaration, Go to implementation, Go to super</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>org.eclipse.jface.text.hyperlink.IHyperlinkDetector</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>org.eclipse.xtext.ui.editor.hyperlinking.DefaultHyperlinkDetector, navigation to EObject URI most interesting: SIGNIFICANT cf. org.eclipse.xtext.resource.ILocationInFileProviderExtension.RegionDescription</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>subclass and bind IHyperlinkHelper (returns an array of possible links, first one is the default)</simpara>
-</listitem>
-<listitem>
-<simpara>also see ILocationInFileProviderExtension (cf. navigation to syntax elements instead of types)</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Syntax_and_Semantic_Coloring">
-<title>Syntax and Semantic Coloring</title>
-<simpara>Coloring based on the lexical tokens or based on the semantic tokens (the parsed model). The parser may treat certain lexical keywords as valid identifiers in some contexts. Some of those should not appear as keywords. Semantic coloring is usually more expensive to compute thus run in the background and with some delay</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Numbers, String literals (lexical) Escape sequences in Strings, method calls, property read / write access (semantic)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara><literal>org.eclipse.jface.text.presentation.IPresentationDamager</literal> <literal>org.eclipse.jface.text.presentation.IPresentationRepairer</literal> <literal>org.eclipse.jface.text.rules.ITokenScanner</literal>
-+
-Scan for tokens and associate text attributes with tokens. Compute the region of the document that has to be recolored after a text change. Tokens may not overlap.
-+
-Also Eclipse provides Themes that are styled via CSS. Coloring can be adjusted to themes where the logical names are mapped to different default values.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara><literal>o.e.x.ui.editor.syntaxcoloring.ITextAttributeProvider</literal> - associate Antlr token names with coloring styles (logical names of text coloring)</simpara>
-</listitem>
-<listitem>
-<simpara><literal>o.e.x.ui.editor.syntaxcoloring.AbstractAntlrTokenToAttributeIdMapper</literal>- convert the antlr tokens to JFace ITokens with proper text applied</simpara>
-</listitem>
-<listitem>
-<simpara><literal>o.e.x.ui.editor.syntaxcoloring.IHighlightingConfiguration</literal> - register logical text colorings with default values, yields a preference page and the proper configuration for the text attribute provider</simpara>
-</listitem>
-<listitem>
-<simpara><literal>o.e.x.ui.editor.syntaxcoloring.ISemanticHighlightingCalculator</literal> - traverse the AST and associate arbitrary ranges of the text with.</simpara>
-</listitem>
-<listitem>
-<simpara>logical coloring names (this is a key to a style stored in the preference store), if multiple styles are returned, styles will be merged if they overlap (and if possible); JFace constraints are implicitly fulfilled</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>subclass DefaultSemanticHighlightingCalculator and bind ISemanticHighlightingCalculator</simpara>
-<itemizedlist>
-<listitem>
-<simpara>traverse resource from left to right (usually order of semantic elements – small performance improvement)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>provide new logical style: subclass DefaultHighlightingConfiguration and bind IHighlightingConfiguration; override configure (see overridden)</simpara>
-</listitem>
-<listitem>
-<simpara>semantic coloring always wins</simpara>
-</listitem>
-<listitem>
-<simpara>only a few decisions can me made in lexical coloring, override lexical:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>subclass <literal>DefaultAntlrTokenToAttributeIdMapper</literal> bind <literal>TokenTypeToStringMapper</literal></simpara>
-</listitem>
-<listitem>
-<simpara>e.g., color jsdoc comments differently to multiline, regex</simpara>
-</listitem>
-<listitem>
-<simpara>e.g. color tags inside jsdocs or regex inside, use semantic coloring</simpara>
-</listitem>
-<listitem>
-<simpara>lexical: different kind of keywords (e.g., N4JS keywords vs. JS keywords)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>change coloring (via toggle button), possible approach:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>(inject singleton into highlighter, state of singleton is changed by toggle button, listen to that object in the editor, calculator cannot be triggered from outside due to UI-thread issues)</simpara>
-</listitem>
-<listitem>
-<simpara>prefered: store state in preference store and get the information then from there in the hightligher, inject PreferencestoreAccess in Calculator</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Code_Formatter">
-<title>Code Formatter</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Auto-Format Source Code, Auto-Format code inserted by code-rewrite</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara><literal>org.eclipse.jface.text.formatter.IContentFormatter</literal> - here is the document and some range - modify at will</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>Declarative Formatting API (to be deprecated) - associate formatting rules with grammar elements New formatting API (mixture of declarative and imperative) - here is the model, do what you want (space before, linebreak after, indentation increase / decrease), the engine will merge your advices and apply them to the document</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<simpara>wait for 2.8 (maybe in 2.7.x)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Wizards">
-<title>Wizards</title>
-<blockquote>
-<attribution>
-Eclipse Help
-</attribution>
-<simpara>Wizards are used to guide the user through a sequenced set of tasks. Your plug-in can contribute wizards at predefined extension points in the workbench. It can also create and launch its own wizards.</simpara>
-</blockquote>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>New N4JS Class</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>Xtend based Wizards</simpara>
-</listitem>
-<listitem>
-<simpara>also see Formular Editor for Embedded Xtext editor</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practices</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>use preferences (could be hidden, so use them even if not made configurable to the user)</simpara>
-</listitem>
-<listitem>
-<simpara>use standard JFace wizard API, use Xtend template expressions for file templates</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Cheat_Sheets">
-<title>Cheat Sheets</title>
-<blockquote>
-<attribution>
-Eclipse Help
-</attribution>
-<simpara>Composite cheat sheets provide guidance through complex problems by breaking the problem into a set of smaller tasks. Composite cheat sheets are registered using the the <literal>org.eclipse.ui.cheatsheets.cheatSheetContent</literal> extension point.</simpara>
-</blockquote>
-<simpara>(In Scala IDE: Work Sheets), often combined with Code Snippets</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Create Hello World Application</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>None, probably the embedded editor could be used in a REPL (Read-Evaluate-Print-Loop)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Context_sensitive_Help">
-<title>Context-sensitive Help</title>
-<blockquote>
-<attribution>
-Eclipse Help
-</attribution>
-<simpara>A focused set of help topics that is related to the current context can be shown to users on demand using context-sensitive help. This form of user assistance is delivered to users when a platform-specific trigger is activated (e.g. F1 key on Windows, Ctrl+F1 on GTK, Help key on Carbon). Until Eclipse 3.1, context-sensitive help was presented in infopop windows. Since 3.1, a new Help view is the preferred way to deliver context-sensitive information to the user.</simpara>
-</blockquote>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Help in Formular Editor, Help about syntax construct, API-Help</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>None</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Hovers">
-<title>Hovers</title>
-<simpara>Hover allow to display additional information as soon as the cursor stays on a certain text region. Some hovers can be requested by shortcuts (e.g. F2) similar to sort of an online help.</simpara>
-<simpara>Different kind of hovers may appear depending on the context, e.g. the error hover will have higher prio than the documentation hover. Different modifier keys may be assigned to request different hover kinds while hovering a region with the mouse. (didn’t a proper code pointer, though)</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Hover over method shows JSDoc, Signatures or inferred types, error / problem details</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara><literal>org.eclipse.jface.text.ITextHover</literal> + <literal>ITextHoverExtension*</literal> - compute hover based on the region that is hovered. Various indirections with <literal>IInformationControl</literal> and <literal>IInformationControlCreator</literal> with many extension interfaces</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara><literal>org.eclipse.xtext.ui.editor.hover.IEObjectHover</literal> - compute hover based on <literal>EObjects</literal></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<simpara>see XBase hover stuff</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Folding">
-<title>Folding</title>
-<simpara>Code folding allows to skip parts of the code that are mandatory semantically but usually do not provide added value for the reader, e.g. import sections</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Import section folding, folding of arbitrary methods or comments</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>Not much there, most of that stuff is implemented specific to JDT or ODE. Projections usually only work per line, that is, a subsection of a line cannot be folded, e.g. it’s not possible to show</simpara>
-<screen>var x = new Map<String, List<Pair<String, Number>>>()</screen>
-<simpara>as</simpara>
-<screen>var x = new Map<...>()</screen>
-<simpara>Line only limitation in SWT (a guess, didn’t work for Sebastian otherwise)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara><literal>org.eclipse.xtext.ui.editor.folding.DefaultFoldingRegionProvider</literal> - here is the resource, compute the folding</simpara>
-</listitem>
-<listitem>
-<simpara><literal>org.eclipse.xtext.ui.editor.folding.DefaultFoldingStructureProvider</literal> - bridge between editor and custom computation, preferences etc would be read from here</simpara>
-</listitem>
-<listitem>
-<simpara>no preference page for folding provided by Xtext</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Best Practice</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>maybe limit to blocks (subclass default, bind to interface)</simpara>
-</listitem>
-<listitem>
-<simpara>probably provide your own folding preference page</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Customizable_validation___severity">
-<title>Customizable validation / severity</title>
-<simpara>Some problems are more important to the user than others so they want to change the severity.</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Deprecation could be an error, warning or ignored (e.g. in test projects)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Eclipse API</simpara>
-</entry>
-<entry>
-<simpara>None</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Xtext Specifics</simpara>
-</entry>
-<entry>
-<simpara>IssueSeverityProvider (since 2.6), Monkey sees monkey does: see subclasses of IssueSeverityProvider (we already do that)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Proposals">
-<title>Proposals</title>
-<simpara>Created by Content Assist, Quick Fixes, Quick Assist.</simpara>
-<simpara>Basics</simpara>
-<itemizedlist>
-<listitem>
-<simpara>simplest case: proposals are strings to be inserted</simpara>
-</listitem>
-<listitem>
-<simpara>or displayed string is different from inserted one (e.g. FQN vs. simple)</simpara>
-</listitem>
-<listitem>
-<simpara>ConfigurableCompletionProposal created via factory methods in AbstractN4JSProposalProvider (*create*Pro)</simpara>
-</listitem>
-<listitem>
-<simpara>PrefixMatcher (by default CamelCase aware) – for filtering, it usually is not necessary to use it when computing the proposal (only if it expensive to compute proposals) – that is, prefix can be ignored when computing a proposal because the prefix matcher will filter out invalid proposals anyway</simpara>
-</listitem>
-<listitem>
-<simpara>pass a filter (Guava preodicate) to filter out (semantically invalid) proposals, cf. lookupCrossReference(..) – for the things where there are proposals created by default</simpara>
-</listitem>
-<listitem>
-<simpara>priority defined by an int – for sorting. Cf. ContentProposalPriorities → define default priorities (constant values) in N4JS, do not add some random integers!</simpara>
-</listitem>
-<listitem>
-<simpara>modes: bind RepeatedContentAssistProcessor and enable modeaware in ProposalProvider (e.g. for private members which require a quickfix)</simpara>
-</listitem>
-<listitem>
-<simpara>what could be done in the background: hover, lazy (not prepared) proposals (cf. JDT), Xtext 2.7.; different situations are processed in parallel</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Several changes (e.g. automatic import):</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>ConfigurableCompletionProposal.setTextApplier</literal></simpara>
-</listitem>
-<listitem>
-<simpara>TextApplier: can open dialogs etc., TextApplier is the callback</simpara>
-</listitem>
-<listitem>
-<simpara>usual case: add text at cursor position and somewhere else:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>get document in TextApplier</simpara>
-</listitem>
-<listitem>
-<simpara>for performance, but also: do not use semantic changes in content assist, because model is broken (you will get funny things) – use model (AST) to get offset, but then insert line breaks etc. → maybe create utility class for retrieving current formattings which are then used in the text edit → maybe provide tools for retrieving certain locations (e.g. import section, field section, etc.)</simpara>
-</listitem>
-<listitem>
-<simpara>do not create model (AST) fragments (which are then serialized), instead directly provide text</simpara>
-</listitem>
-<listitem>
-<simpara>use TextEdit and MultiTextEdit</simpara>
-</listitem>
-<listitem>
-<simpara>set TextViewer redraw to false and to true after the text edits were applied</simpara>
-</listitem>
-<listitem>
-<simpara>have proper TESTS to ensure that file is not broken after the changes</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">LinkedEditing</emphasis>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Linked-Editing mode in ConfigurableCompletionProposal with one editing group only (basically: move the cursor somewhere after editing it, see setSimpleLinkedMode)</simpara>
-</listitem>
-<listitem>
-<simpara>do it manually: cf. LinkedPositionGroup (see call hierarchy of constructor) – used for quick fixes or refactorings rather for content assist</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-<section xml:id="sec:Non_Eclipse_UI_Concepts">
-<title>Non-Eclipse UI Concepts</title>
-<simpara>The following entries are not necessarily implemented yet.</simpara>
-<section xml:id="sec:Overlays">
-<title>Overlays</title>
-<simpara>An overlay is a small annotation similar to an hover, attached to a specific location in the editor and is moved with that location.</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Examples</simpara>
-</entry>
-<entry>
-<simpara>Show inferred types</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Goto__Inferred__Type">
-<title>Goto (Inferred) Type</title>
-<simpara>Navigate to an inferred type (or other <literal>invisible</literal> information)</simpara>
-</section>
-<section xml:id="sec:Postfix_Completion">
-<title>Postfix Completion</title>
-<simpara>(IntelliJ) Replace code <emphasis>AFTER</emphasis> an expression</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_user-interface-resources">
-<title>User Interface Resources</title>
-<section xml:id="_icons">
-<title>Icons</title>
-<simpara>In parts, the N4JS IDE re-uses some of the icons that come with the Eclipse Platform as well as the Eclipse JDT development environment. However, in some cases we also provide our own icons to illustrate N4JS-specific concepts.</simpara>
-<section xml:id="_eclipse-platform-icons">
-<title>Eclipse Platform Icons</title>
-<simpara>When re-using the Eclipse Platform Icons, the icons are usually copied over to the <literal>icons/</literal> folder of the <literal>org.eclipse.n4js.ui</literal> bundle. In this folder, the <literal>README.adoc</literal> file keeps book on the origin of all the collected icons (e.g. different Eclipse Projects).</simpara>
-</section>
-<section xml:id="_n4js-specific-icons">
-<title>N4JS Specific Icons</title>
-<simpara>In some cases, the icons the Eclipse eco-system provides do not suffice to sensibly express N4JS concepts. In these cases we provide our own icons. When designing those we try to imitate the general Eclipse artstyle in order for our icons to integrate well with the overall appearance of Eclipse.</simpara>
-<simpara>For the creation of new icons, the <literal>eclipse-svg-icons</literal> repository (see <link xl:href="https://github.com/Seung-Yoon/eclipse-svg-icons">https://github.com/Seung-Yoon/eclipse-svg-icons</link>) has proven helpful. The repository contains raw SVG files which can be used to reproduce the bitmap icons that are contained in, for instance, the <literal>org.eclipse.platform.ui</literal> or <literal>org.eclipse.jdt.ui</literal> bundle. Based on that, common vector-graphics editing software may be used to further adapt color, form and style of existing icons (e.g. Inkscape <link xl:href="https://inkscape.org/en/">https://inkscape.org/en/</link>).</simpara>
-</section>
-<section xml:id="_high-resolution-icons">
-<title>High Resolution Icons</title>
-<simpara>With the Neon release, Eclipse SWT introduced explicit support for high-DPI monitors (see <link xl:href="https://www.eclipse.org/eclipse/news/4.6/platform.php#swt-autoscale">https://www.eclipse.org/eclipse/news/4.6/platform.php#swt-autoscale</link>). In order to provide a good user experience, we want to provide high-DPI support for as many of our icons as possible. For that, it suffices to simply provide an alternative resource with higher resolution by appending the prefix @2x to its name (e.g. <literal>class.png</literal> and <literal>class@2x.png</literal>). Code-wise, no adjustments are required. In case of copied Eclipse Platform Icons, most of the time a corresponding 2x-version can be obtained from the original source. In case of N4JS Specific Icons, we export all icons in the resolutions 16x16 and 32x32. For that, it is of particular importance to make sure that the scaling is done in accordance with the native resolution (cf. pixel perfect scaling, also see <link xl:href="https://en.wikipedia.org/wiki/Native_resolution">https://en.wikipedia.org/wiki/Native_resolution</link>).</simpara>
-</section>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_formatting">
-<title>Formatting</title>
-<warning>
-<simpara>This chapter may be outdated.</simpara>
-</warning>
-<section xml:id="sec:FmtObjective" role="language-n4js">
-<title>Objective</title>
-<simpara>Writing textual code has many degrees of freedom. The resulting layout differs between authors. Carefully placing whitespace and newlines can increase the readability. Some handling of whitespace can be automated. This chapter describes the techniques used to automate the formatting to some degree.</simpara>
-<simpara>Formatting N4js source code ensures a consistent style. It takes care of:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>surrounding language constructs with white space to improve readability</simpara>
-</listitem>
-<listitem>
-<simpara>indenting logically grouped elements</simpara>
-</listitem>
-<listitem>
-<simpara>wrapping long lines of code and comments</simpara>
-</listitem>
-<listitem>
-<simpara>inserting semicolons, which would otherwise be automatically inserted (ASI)</simpara>
-</listitem>
-<listitem>
-<simpara>formatting documentation</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Formatting will never alter the semantics of the code and it will not reorganize it.</simpara>
-<section xml:id="sec:FmtFormatting_Comments">
-<title>Formatting Comments</title>
-<simpara>N4js distinguishes five different types of comments <emphasis>single line comments</emphasis>, <emphasis>not-indented single line comments</emphasis>, <emphasis>multiline comments</emphasis>, <emphasis>fixed multiline comments</emphasis> and <emphasis>Jsdoc style multiline comments.</emphasis></simpara>
-<simpara>Single line comments start with <literal>//</literal> and include all characters until the end of line. They usually will be indented and wrapped if they exceed the maximum line length unless they start immediately at the first column. Single line comments starting at position 0 are called <emphasis>not-indented single line comments</emphasis>.</simpara>
-<simpara>Multiline comments start with <literal>/*</literal> and span all character including line breaks up the the end given by <literal>*/</literal> . The three variants are distinguished by the third and fourth character:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Comments starting with <literal>/*-</literal> are always fixed multiline comments.</simpara>
-</listitem>
-<listitem>
-<simpara>Comments starting with <literal>/**</literal> and following any other character but <literal>*</literal> are Jsdoc style multiline comments. (E.g. <literal>/**+</literal> start Jsdoc but <literal>/***</literal> does not.)</simpara>
-</listitem>
-<listitem>
-<simpara>All others starting with <literal>/*</literal> are ordinary multiline comments.</simpara>
-</listitem>
-</itemizedlist>
-<simpara><emphasis>Not-indented single line comments</emphasis> and <emphasis>fixed multiline comments</emphasis> will always remain as they are. Usually they are used to comment out code sections.</simpara>
-</section>
-</section>
-<section xml:id="sec:FmtArchitecture" role="language-n4js">
-<title>Architecture</title>
-<simpara>Formatting mainly takes place in polymorphic dispatch methods <literal>format</literal> in class <literal>N4JSFormatter</literal>. Some language features are formatted with an entry-point using a super-class. This is mainly the case for structures that are sufficiently similar. E.g. <literal>format( FunctionOrFieldAccessor )</literal> is responsible for getter, setter, methods, functions, ….</simpara>
-<simpara>Some common source-code formattings are grouped by <literal>configureXY()</literal> methods. They get called from the <literal>format</literal> methods for similar code structures, c.f. <literal>configureAnnotations</literal></simpara>
-<simpara>Since we do not support formatting of the TypeExpression-language stand-alone, this class provides only one format-method throwing an <literal>UnsupportedOperationException</literal> type expressions formatting is defined in class <literal>N4JSFormatter</literal> at the end of the file.</simpara>
-<figure xml:id="fig:formatter_overview" role="center">
-<title>Overview of classes used for formatting</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/17_formatting/images/FormatterArchitecture.svg"/>
-</imageobject>
-<textobject><phrase>FormatterArchitecture</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The first entry-point for a script is <literal>N4JSFormatter.format(Script, IFormattableDocument)</literal>. Within this method an instance of <literal>N4JSGenericFormatter</literal> is created and used to configure general aspects of automatic-semicolon insertion (put a ’<literal>;</literal>’ where ASI took place in the parser) and handling of colons (’<literal>:</literal>’).</simpara>
-<section xml:id="sec:Implementation_example">
-<title>Implementation example</title>
-<simpara>Considering the following N4js-snippet where the return value of a function call will be casted to some type.</simpara>
-<screen>functionCall("a","b") as MyType<string></screen>
-<simpara>The whole line is a CastExpression comprising of an expression (<literal>functionCall(a,b)</literal>) and a type reference (<literal>MyType<string></literal>).</simpara>
-<simpara>The <literal>format</literal>-dispatch method written in Xtend would look like:</simpara>
-<screen> def dispatch void format(CastExpression expr, extension IFormattableDocument document) {
- expr.regionFor.keyword("as").prepend[newLines = 0; oneSpace].append[newLines = 0; oneSpace];
- expr.expression.format;
- expr.targetTypeRef.format;
- }</screen>
-<simpara>In line 2 the format around the keyword <literal>as</literal> is specified where in line 3 and 4 the formatting of the containing elements will be dispatched.</simpara>
-<simpara>Note that <literal>regionFor</literal> in line 2 is a method declared in <literal>IFormattableDocument</literal> and used via the extension-parameter <literal>document</literal>. It returns an object of type <literal>ISemanticRegionFinder</literal>. Invoking the <literal>keyword</literal> method on this object returns an instance of <literal>ISemanticRegion</literal> which will be passed to the extension methods <literal>prepend</literal> and <literal>append</literal> following the builder pattern. Both <literal>prepend</literal> and <literal>append</literal> take a lambda expression operating on a single parameter of type <literal>IHiddenRegionFormatter</literal>. Inside the lambda-expression this parameter is implicitly used to invoke the methods <literal>setNewLines(0)</literal> and <literal>oneSpace()</literal>. These calls simply disallow line-breaks around as and force the whitespace to be just a single character.</simpara>
-<simpara>Possible other formatting instructions can be found in <literal>IHiddenRegionFormatter</literal>.</simpara>
-<simpara>Due to some bugs in auto-wrapping<footnote><simpara>version at the time of writing is Xtext 2.12</simpara></footnote> unsuccessful attempts to wrap a line can insert unexpected new-lines in regions several lines in front of the currently treated source-line.</simpara>
-<simpara>Debugging the formatter can be cumbersome as, due to GH-12<footnote><simpara><link xl:href="https://github.com/eclipse/xtext-core/issues/12">https://github.com/eclipse/xtext-core/issues/12</link></simpara></footnote>, the <literal>toString()</literal> methods if internal data-structures throw exceptions.</simpara>
-</section>
-</section>
-<section xml:id="sec:FmtFormatter_Implementation_Guidelines">
-<title>Formatter Implementation Guidelines</title>
-<itemizedlist>
-<listitem>
-<simpara>Each formatted element should only format it’s inner content. This avoids conflicting situations.</simpara>
-</listitem>
-<listitem>
-<simpara>For each region possibly containing whitespace must be formatted.</simpara>
-</listitem>
-<listitem>
-<simpara>Use priorities for conflict-resolutions sparse. For contradicting informations in the same region, the higher priority wins. If both information have the same priority, then an Exception will be thrown, showing two stack-traces to indicate the two code-regions being responsible for the situation.</simpara>
-</listitem>
-<listitem>
-<simpara>For auto-wrapping a callback can be registered. In case of wrapping you can then conditionally change the format. Registering a callback implicitly sets the auto-wrap flag for the region.</simpara>
-</listitem>
-<listitem>
-<simpara>Cover formatting with at least two different unit-tests. One having as little white-space as possible (all in one line) and the other as much white-space as possible in order to identify unformatted regions.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:FmtConfiguration">
-<title>Configuration</title>
-<simpara>Some formattings can be customised through preference key-value pairs. Class <literal>N4JSFormatterPreferenceKeys</literal> acts as the entry-point to define such key-(default-)value pairs. Some preferences are inherited and are based on values stored in the default preference store (Line length, default tab width, …).</simpara>
-<simpara>Currently the preferences are not yet accessible by the end-user.</simpara>
-</section>
-<section xml:id="sec:FmtUI_Integration">
-<title>UI Integration</title>
-<simpara>Code formatting is invoked with standard key-strokes ( <keycap>CMD</keycap>+<keycap>Shift</keycap>+<keycap>F</keycap> on Mac, <keycap>Ctrl</keycap>+<keycap>Shift</keycap>+<keycap>F</keycap> on Windows)</simpara>
-<simpara>There is no UI for preferences values yet.</simpara>
-</section>
-<section xml:id="sec:FmtUnit_Testing_with_Xpect" role="language-n4js">
-<title>Unit Testing with Xpect</title>
-<simpara>With Xpect Method <literal>formattedLines</literal> implemented in class <literal>org.eclipse.n4js.xpect.FormatterXpectMethod</literal> in bundle <literal>org.eclipse.n4js.tests.helper</literal> the formatting can be tested. The test method requires the number of lines which should be formatted. The desired test is given as a standard multiline expectation.</simpara>
-<screen>/* XPECT formattedLines 1 ---
-var a, b, c, d, e;
---- */
-var a,b,c,d,e;</screen>
-<simpara>Preferences can be configured in the Xpect setup section by providing string values. Numbers and booleans are converted automatically by the preferences framework.</simpara>
-<screen>/* XPECT_SETUP org.eclipse.n4js.tests.N4JSXpectTest
- ResourceSet {
- ThisFile {}
- File "wishesImported.n4js" { }
- }
- Preference "indentation" " " {}
- Preference "line.width.max" "100" {}
- Preference "format.auto_wrap_in_front_of_logical_operator" "false" {}
-
- END_SETUP
- */</screen>
-<simpara>Tip: Full coverage of the formatting can be tested via authoring the input using spaces as indentation characters if the formatter would use tabs or vice versa. That way untouched lines are distinguishable during the test-runs</simpara>
-</section>
-</chapter>
-<chapter xml:id="_external-libraries">
-<title>External Libraries</title>
-<simpara></simpara>
-<sidebar>
-<simpara><link xl:href="https://github.com/eclipse/n4js/issues/1018"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #1018</link>
-<link xl:href="https://github.com/eclipse/n4js/issues/397"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #397</link>
-<link xl:href="https://github.com/eclipse/n4js/issues/809"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #809</link>
-<link xl:href="https://github.com/eclipse/n4js/issues/714"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #714</link>
-<link xl:href="https://github.com/eclipse/n4js/issues/653"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #653</link>
-<link xl:href="https://github.com/eclipse/n4js/issues/862"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #862</link>
-<link xl:href="https://github.com/eclipse/n4js/issues/1133"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #1133</link></simpara>
-</sidebar>
-<simpara><emphasis role="strong">External libraries</emphasis> are N4JS projects that are provided by the N4JS IDE:
-the <emphasis>built-in</emphasis>/<emphasis>shipped</emphasis> libraries, and all <emphasis>3rd-party libraries</emphasis> that were installed by the <emphasis>N4JS library manager</emphasis>.
-Each external library consist of a valid package.json file located in the project root and an arbitrary number of files supported by N4JS projects, e.g. <emphasis>.n4js</emphasis>, <emphasis>.njsd</emphasis> and <emphasis>.js</emphasis> files.
-The purpose of the external libraries is to share and to provide core and third party functionality for N4JS developers both in compile and runtime without rebuilding them.</simpara>
-<simpara><xref linkend="sec:Built-in_External_Libraries"/> are external libraries that provide some basic functionality for N4JS programmers, such as the class <literal>N4Injector</literal>.</simpara>
-<simpara><emphasis role="strong">3rd-party libraries</emphasis> are external libraries that are not built-in/shipped with the N4JS IDE.
-Instead, they can be installed later by the user from third party providers.
-Currently, only <emphasis>npm packages</emphasis> are supported.</simpara>
-<simpara>The <emphasis role="strong">N4JS index</emphasis> is populated when the external libraries are compiled.
-However, this compilation is only triggered through the library manager, but not when building workspace projects. (Self-evidently, the index is also populated when compiling workspace projects.)</simpara>
-<simpara><emphasis role="strong">Name clashes</emphasis> of projects can happen and they are solved in the following order:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>User workspace projects always shadow external libraries.</simpara>
-</listitem>
-<listitem>
-<simpara>In case of a name clash between a shipped and a 3rd-party library, the 3rd-party library shadows the shipped project.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The <emphasis role="strong">N4JS library manager</emphasis> is a tool in the N4JS IDE to view and manage external libraries.
-In particular, the user can (un-)install new 3rd-party libraries, or can trigger the build of all external libraries to re-populate the N4JS index.
-The library manager also supports other maintenance actions such as deleting all 3rd-party libraries.</simpara>
-<section xml:id="sec:Major_Components" role="language-n4js">
-<title>Major Components</title>
-<simpara>External libraries are supported based on different components all over the application.</simpara>
-<simpara>The followings are the most important ones:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis role="strong">External Resources</emphasis> (<literal>IExternalResource</literal>)</simpara>
-<itemizedlist>
-<listitem>
-<simpara>These are customized <literal>IResource</literal> implementations for external projects, folders and files.</simpara>
-</listitem>
-<listitem>
-<simpara>With this approach the <literal>IProject</literal>, <literal>IFolder</literal> and <literal>IFile</literal> interfaces have been implemented. Each implementation is backed by a pure <literal>java.io.File</literal> based resource.</simpara>
-</listitem>
-<listitem>
-<simpara>When accessing such external resources for example visiting purposes, getting the members of the resource or simply deleting the resource, internally each requests will be directly performed on the wrapped <literal>java.io.File</literal> without accessing the <literal>org.eclipse.core.resources.IWorkspace</literal> instance.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">External Library Workspace</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>This is a kind of dedicated workspace for external libraries and their dependencies.</simpara>
-</listitem>
-<listitem>
-<simpara>Any query requests to retrieve a particular project or any dependencies of a particular project via the <literal>IN4JSCore</literal> singleton service will delegated to its wrapped <literal>N4JSModel</literal> singleton. Internally the <literal>N4JSModel</literal> has a reference to a workspace for all the ordinary workspace projects and another reference to the workspace for external libraries. Each query requests will be forwarded to the workspace for the ordinary projects first, and then to the external library workspace. If ordinary project workspace can provide any meaningful response for a request, then the external library workspace will not be accessed at all. Otherwise the query will be executed against the external library workspace. This fallback mechanism provides a pragmatic solution to the project shadowing feature. The project shadowing will be described in details later in this section.</simpara>
-</listitem>
-<listitem>
-<simpara>The <emphasis role="strong">External Library Workspace</emphasis> is only supported and available in the IDE case, in the headless case there are no external libraries available from this dedicated workspace. Since the Xtext index creation and the entire build infrastructure is different, it is supported via target platform file. This is described in more details in a later section (<link linkend="sec:Headless_External_Library_Support">Headless External Library Support</link>]).</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">External Library Preference Store</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>This preference store is being used to register and un-register external library root folders into its underlying ordered list. A folder is called as an external library root folder if it is neither equal with the Eclipse workspace root nor being nested in the workspace root and contains zero to any external libraries.</simpara>
-</listitem>
-<listitem>
-<simpara>Whenever any modifications are being saved in this preference store the <emphasis>External Library Workspace</emphasis> will be updated as well, new libraries will be registered into the workspace and removed libraries will be cleaned up from the workspace.</simpara>
-</listitem>
-<listitem>
-<simpara>When the N4JS IDE application is started in production mode, the initial state of the preference store is being pre-populated with default values. This is necessary to provide built-in libraries to end users. These default values and additional advanced configurations will be mentioned in more details later in this section.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Library Manager</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>This service is responsible for downloading and installing third party <emphasis>npm</emphasis> packages into the <literal>node_modules</literal> folder of the N4JS IDE. After downloading, the newly-installed and/or updated packages are registered as external libraries into the system.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">External Library Builder</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>This service is responsible for updating the persistent Xtext index with the currently available external libraries.</simpara>
-</listitem>
-<listitem>
-<simpara>Unlike in case of any other ordinary projects, this builder does not triggers a build via the <literal>org.eclipse.core.internal.events.BuildManager</literal> but modifies the persisted Xtext index (<literal>IBuilderState</literal>) directly.</simpara>
-</listitem>
-<listitem>
-<simpara>Considers shadowed external libraries when updating the persisted Xtext index.</simpara>
-</listitem>
-<listitem>
-<simpara>Makes sure that the external library related Xtext index is persistent and will be available on the next application startup.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">External Library Xtext Index Persister</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>This class is responsible for recovering the consistent external library Xtext index state at application startup.</simpara>
-</listitem>
-<listitem>
-<simpara>Scheduled on the very first application startup to prepare the Xtext index for the available external libraries.</simpara>
-</listitem>
-<listitem>
-<simpara>Recovers the Xtext index state after a force quit and/or application crash.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">External Library Preference Page</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>Preference page to configure and update the state of the <emphasis>External Library Preference Store</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara>Provides a way to install <emphasis>npm</emphasis> dependencies as external libraries into the application.</simpara>
-</listitem>
-<listitem>
-<simpara>Reloads the external libraries. Gets the most recent state of N4JS type definition files and updates the Xtext index content based on the current state of the external libraries.</simpara>
-</listitem>
-<listitem>
-<simpara>Exports the current npm dependency configuration as a target platform file. This will be discussed in another section ([sec:Headless_External_Library_Support]).</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Miscellaneous UI Features</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>Searching for types provided by external libraries.</simpara>
-</listitem>
-<listitem>
-<simpara>Opening external modules in read-only editor.</simpara>
-</listitem>
-<listitem>
-<simpara>Navigation between external types.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Project Explorer</emphasis> contribution for showing external dependencies for ordinary workspace projects.</simpara>
-</listitem>
-<listitem>
-<simpara>Editor-navigator linking support for external modules.</simpara>
-</listitem>
-<listitem>
-<simpara>Installing third party npm dependencies directly from package.json editor via a quick fix.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-<section xml:id="subsec:External_Resources">
-<title>External Resources</title>
-<simpara>This approach provides a very pragmatic and simple solution to support external libraries in both in the <literal>IN4JSCore</literal> and in the <literal>IBuilderState</literal>. While <literal>IN4JSCore</literal> supports a completely transparent way of external libraries via the <literal>IN4JSProject</literal> interface all over in the application, the <literal>IBuilderState</literal> is responsible for keeping the Xtext index content up to date with the external libraries. Below picture depicts the hierarchy between the ordinary <literal>IResource</literal> and the <literal>IExternalResource</literal> instances. As described above each external resource is backed by a <literal>java.io.File</literal> resource and each access and operation being invoked on the <literal>IResource</literal> interface will be delegated to this backing resource.</simpara>
-<figure xml:id="fig:External_Resources_Hierarchy" role="center">
-<title>External Resources Hierarchy</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/20_externalLibraries/images/externalResources.svg"/>
-</imageobject>
-<textobject><phrase>externalResources</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="subsec:External_Library_Workspace">
-<title>External Library Workspace</title>
-<simpara>External library workspace is an extension of the <literal>InternalN4JSWorkspace</literal>. This workspace is used for storing and managing external libraries all over the application. External libraries can be registered into the workspace by providing one to many external library root folder locations. The provided root folder locations will be visited in an ordered fashion and the contained external libraries (N4JS projects) will be registered into the application. If an external library from a root folder has been registered, then a forthcoming occurrence of an external library with the same artefact identifier (and same folder name) will be ignored at all. For instance let assume two external library root locations are available <literal>ER1</literal> and <literal>ER2</literal>, also <literal>ER1</literal> contains <literal>P1</literal> and <literal>P2</literal> external libraries, while <literal>ER2</literal> contains <literal>P2</literal> and <literal>P3</literal>. After registering the two roots into the workspace <literal>ER1</literal> will be processed first, and <literal>P1</literal> and <literal>P2</literal> will be registered to the workspace, when processing the forthcoming <literal>ER2</literal> root, <literal>P2</literal> will be ignored at all as an external with the same name exists. Finally <literal>P3</literal> will be registered to the workspace. External libraries cannot be registered directly into the workspace it is done automatically by the <emphasis>External Library Preference Store</emphasis> and by the <emphasis>npm Manager</emphasis>.</simpara>
-</section>
-<section xml:id="subsec:External_Library_Preference_Store">
-<title>External Library Preference Store</title>
-<simpara>This persistent cache is used for storing an ordered enumeration of registered external library root folder locations. Whenever its internal state is being persisted after a modification, all registered modification listeners will be synchronously notified about this change. All listeners will receive the store itself with the updated state. There are a couple of registered listeners all over the application listening to store update events but the most important one is the <emphasis>External Library Workspace</emphasis> itself. After receiving an external library preference store update event, the external library workspace will calculate the changes from its own state: creates a sort of difference by identifying added, removed and modified external libraries. Also tracks external library root location order changes. Once the workspace has calculated the changes<footnote><simpara>Calculates a list of external library projects that have to be build and another list of projects that have to be cleaned.</simpara></footnote> it will interact with the <emphasis>External Library Builder Helper</emphasis> which will eventually update the persisted Xtext index directly through the <literal>IBuilderState</literal>. After the Xtext index content update all ordinary workspace projects that directly depend either on a built or a cleaned external library will be automatically rebuilt by the external library workspace.</simpara>
-</section>
-<section xml:id="subsec:npm_Manager">
-<title>Library Manager</title>
-<simpara>This service is responsible for downloading, installing third party npm dependencies into the local file system. This is done directly by <literal>npm</literal> from <literal>Node.js</literal>. Once an npm package has been downloaded and installed it will be registered into the external library workspace. As part of the registration, the Xtext index content will be updated and all dependent ordinary workspace projects will be rebuilt automatically. An npm package cannot be installed via the <emphasis>Library Manager</emphasis> if it already installed previously.</simpara>
-</section>
-<section xml:id="subsec:External_Library_Builder_Helper">
-<title>External Library Builder</title>
-<simpara>This builder is responsible for updating the persisted Xtext index state with external library content directly through the <literal>IBuilderState</literal>. When providing a subset of external libraries to either build or clean, internally it orders the provided external libraries based on the project dependencies. Also, it might skip building all those external libraries that have are being shadowed by a workspace counterpart. An external library is being shadowed by an ordinary workspace project, if the workspace project is accessible and has exactly the same project name as the external library.</simpara>
-</section>
-<section xml:id="subsec:External_Library_Xtext_Index_Persister">
-<title>External Library Xtext Index Persister</title>
-<simpara>By default Xtext provides a way to fix corrupted index or to recreate it from scratch in case of its absence. Such inconsistent index states could occur due to application crashes or due to non-graceful application shutdowns. Although this default recovery mechanism provided by Xtext works properly, it is provided only for projects that are available in the Eclipse based workspace (<literal>org.eclipse.core.resources.IWorkspace</literal>) but non of the external libraries are not available from the Eclipse based workspace, so inconsistent external library index content cannot be recovered by this default mechanism. N4JS IDE contributes its own logic to recover index state of external N4JS libraries. When the default Xtext index recovery runs, then it will trigger a external reload as well. This external reload is guaranteed to run always after the default recovery mechanism.</simpara>
-</section>
-<section xml:id="subsec:External_Library_Preference_Page">
-<title>External Library Preference Page</title>
-<simpara>This preference page provides a way to configure the external libraries by adding and removing external library root folders, also allows the user to reorder the configured external library root locations. Besides that, npm packages can be installed into the application as external libraries. Neither removing nor reordering built-in external libraries are supported, hence these operations are disabled for built-ins on the preference page. No modifications will take effect unless the changes are persisted with the <literal>Apply</literal> button. One can reset the configurations to the default state by clicking on the <literal>Restore Defaults</literal> button then on the <literal>Apply</literal> button. The <literal>Reload</literal> button will check whether new type definition files are available for npm dependencies, then reloads the persistent Xtext index content based on the available external libraries. Once the external library reloading has been successfully finished, all dependent workspace projects will be rebuilt as well. From the preference page one can export the installed and used third party npm packages as a target platform. This exported target platform file can be used with the headless compiler. After setting up the headless compiler with this exported target platform file, the headless tool will collect and download all required third party npm dependencies.</simpara>
-</section>
-</section>
-<section xml:id="sec:Headless_External_Library_Support" role="language-n4js">
-<title>Headless External Library Support</title>
-<simpara>The headless compiler is not capable of supporting built-in libraries. The whole build and Xtext index creation infrastructure is different in the IDE and in the headless case. Also, due to its archive nature (<literal>n4jsc.jar</literal>) of the headless tool, neither the runtime nor the <literal>Mangelhaft</literal> libraries can be loaded into the headless compiler.</simpara>
-<simpara>The headless compiler supports downloading, installing and using third party <literal>npm</literal> packages. To enable this feature one has to configure the target platform via the <literal>–targetPlatformFile</literal> (or simply <literal>-tp</literal>) and the <literal>–targetPlatformInstallLocation</literal> (or simply <literal>-tl</literal>) arguments.</simpara>
-<simpara>If the target platform file argument is configured, then all third party dependencies declared in the target platform file will be downloaded, installed and made available for all the N4JS projects before the compile (and run) phase. If the target platform file is given but the target platform install location is not specified (via the <literal>–targetPlatformInstallLocation</literal> argument), then a the compilation phase will be aborted and the execution will be interrupted.</simpara>
-<simpara>For more convenient continuous integration and testing purposes there are a couple of additional exception cases with respect to the the target platform file and location that users of the headless compiler have to keep in mind. These are the followings:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>–targetPlatformSkipInstall</literal>. Usually dependencies defined in the target platform file will be installed into the folder defined by option <literal>–targetPlatformInstallLocation</literal>. If this flag is provided, this installation will be skipped, assuming the given folder already contains the required files and everything is up-to-date. Users have to use this flag with care, because no checks will be performed whether the location actually contains all required dependencies.</simpara>
-</listitem>
-<listitem>
-<simpara>If <literal>–targetPlatformSkipInstall</literal> is provided the <literal>–targetPlatformInstallLocation</literal> parameter is completely ignored.</simpara>
-</listitem>
-<listitem>
-<simpara>If <literal>–targetPlatformSkipInstall</literal> is provided the <literal>–targetPlatformFile</literal> parameter is completely ignored.</simpara>
-</listitem>
-<listitem>
-<simpara>If neither <literal>–targetPlatformInstallLocation</literal> not <literal>–targetPlatformFile</literal> parameters are specified the headless tool will treat this case as an implicit <literal>–targetPlatformSkipInstall</literal> configuration.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If the target platform install location is configured, and the target platform file is given as well, then all third party dependencies specified in the target platform file will be downloaded to that given location. If the target platform file is given, but the target platform install location is not specified, then a the compilation phase will be aborted and the execution will be interrupted.</simpara>
-<programlisting language="bash" linenumbering="unnumbered">java -jar n4jsc.jar -projectlocations /path/to/the/workspace/root -t allprojects -tp /absolute/path/to/the/file -tl /path/to/the/target/platform/install/location -rw nodejs -r moduleToRun</programlisting>
-<section xml:id="_custom-npm-settings">
-<title>Custom npm settings</title>
-<simpara>In some cases there is a need for custom npm settings, e.g. custom npm registry. Those kind of configurations are
-supported via <literal>.npmrc</literal> file (see <link xl:href="https://docs.npmjs.com/files/npmrc">https://docs.npmjs.com/files/npmrc</link>).</simpara>
-<simpara>In N4JSIDE user can specify path to his custom configuration file in the preference page.</simpara>
-<simpara>For the commandline N4JSC.jar provides special option <literal>-npmrcRootLocation</literal> that allows headless compiler to
-use custom settings.</simpara>
-</section>
-</section>
-<section xml:id="sec:lmFutureWork">
-<title>Future Work</title>
-<simpara>Some aspects not covered in current design, but worth consideration in the future</simpara>
-<section xml:id="subsec:lmMultipleDependencyScope">
-<title>Multiple Dependency Scope</title>
-<simpara>npm scope dependencies</simpara>
-<variablelist>
-<varlistentry>
-<term><emphasis role="strong">DEPENDENCY_DEVELOPMENT</emphasis> </term>
-<listitem>
-<simpara><link xl:href="https://docs.npmjs.com/files/package.json#devdependencies">https://docs.npmjs.com/files/package.json#devdependencies</link></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis role="strong">DEPENDENCY_PEER</emphasis> </term>
-<listitem>
-<simpara><link xl:href="https://docs.npmjs.com/files/package.json#peerdependencies">https://docs.npmjs.com/files/package.json#peerdependencies</link></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis role="strong">DEPENDENCY_BUNDLE</emphasis> </term>
-<listitem>
-<simpara><link xl:href="https://docs.npmjs.com/files/package.json#bundleddependencies">https://docs.npmjs.com/files/package.json#bundleddependencies</link></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis role="strong">DEPENDENCY_OPTIONAL</emphasis> </term>
-<listitem>
-<simpara><link xl:href="https://docs.npmjs.com/files/package.json#optionaldependencies">https://docs.npmjs.com/files/package.json#optionaldependencies</link></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis role="strong">DEPENDENCY_PROVIDES</emphasis> </term>
-<listitem>
-<simpara><link xl:href="http://www.rpm.org/wiki/PackagerDocs/Dependencies#Provides">http://www.rpm.org/wiki/PackagerDocs/Dependencies#Provides</link></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis role="strong">DEPENDENCY_WEAK</emphasis> </term>
-<listitem>
-<simpara><link xl:href="http://www.rpm.org/wiki/PackagerDocs/Dependencies#Weakdependencies">http://www.rpm.org/wiki/PackagerDocs/Dependencies#Weakdependencies</link></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="subsec:lmRunTestsFromLibrary">
-<title>Run Tests from TestLibrary</title>
-<simpara>Imagine we are implementing some API, and we want to run tests for that API. Tests are delivered to us as separate package, and there is not direct association between implementation and test projects (tests are not depending on implementation). Still we want to run provided tests to see if our implementation complies with API tests, e.g. AcceptanceTest suite for Application written against application sdk.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="sec:JSON_Support">
-<title>JSON Support</title>
-<warning>
-<simpara>This chapter may be outdated.</simpara>
-</warning>
-<section xml:id="sec:JSON_Parser">
-<title>JSON Parser</title>
-<simpara>For the JavaScript Object Notation format, a multitude of specifications exist (e.g. [<link linkend="RFC8259">RFC8259</link>], [<link linkend="ECMA404">ECMA404</link>], [<link linkend="RFC7158">RFC7158</link>]). While all specifications agree on the basic structure of JSON, many special cases exist, which remain un-addressed by the specifications. Therefore, in practice many parsers exhibit implementation-specific behavior. See [<link linkend="Ser18">Ser18</link>] for a discussion of many of these cases.</simpara>
-<simpara>The initial grammar of the N4JS JSON parser is mostly based on [<link linkend="ECMA404">ECMA404</link>] while further adaptions have been made to accommodate for special cases such as escaping unicode control characters in string literals. This section discusses the different aspect in which our parser exhibits special behavior in order to parse a maximum of real-world JSON text. If applicable, we will also discuss differences between JSON and the N4JS syntax for object literals.</simpara>
-<section xml:id="sec:JSON_Parser_Unicode_Escaping">
-<title>Escaping Unicode Control Characters in String Literals</title>
-<simpara>In comparison to ECMAScript (and thus N4JS), JSON only requires the escaping of unicode control characters in the range from <literal>U+0000</literal> to <literal>U+001F</literal> when used in a string literal. This includes the line termination characters <literal>U+000A</literal> or <literal>\n</literal> and <literal>U+000D</literal> or <literal>\r</literal>. However, different from ECMAScript, JSON allows the unescaped use of the unicode characters <literal>U+2028</literal> and <literal>U+2029</literal> within string literals. Therefore, the JSON parser differs from the behavior of the N4JS parser.</simpara>
-</section>
-<section xml:id="sec:JSON_Parser_Empty_Text">
-<title>Empty Text</title>
-<simpara>While the abovementioned JSON specifications do not allow for empty JSON text (e.g. no data, only whitespace data), our parser is tolerant towards such inputs. The reason behind this decision is that it allows users of the N4JS IDE, to create new empty JSON files without experiencing any parser errors.</simpara>
-</section>
-<section xml:id="sec:JSON_Parser_Nested_Structures">
-<title>Nested Structures</title>
-<simpara>Since the N4JS JSON parser is implemented in terms of a recursive decent parser, the parsable inputs are limited in terms of nesting. This results in a stack overflow exception for highly nested input data.</simpara>
-</section>
-<section xml:id="sec:JSON_Parser_Whitespace">
-<title>Whitespace</title>
-<simpara>[<link linkend="RFC7158">RFC7158</link>] and [<link linkend="ECMA404">ECMA404</link>] both define whitespace characters of JSON to be exclusively <literal>U+0009</literal>, <literal>U+000A</literal>, <literal>U+000D</literal> and <literal>U+0020</literal>. However, for now we adopt the whitespace strategy of the N4JS parser, which allows for additional whitespace characters (also see [<link linkend="ECMA15a">ECMA15a</link>] section 7.2 White Space). This only applies to JSON text outside of string literals.</simpara>
-</section>
-<section xml:id="sec:JSON_Parser_Comments">
-<title>Comments</title>
-<simpara>Although JSON as a standard does not specify any notion of source code comments, we allow them on a parser level. (single line comments introduced by <literal>//</literal> and multi-line comments using <literal>/*</literal> and <literal>*/</literal>). After parsing, we issue corresponding validation messages that indicate to the user, that such comments will possibly not be parsable in a different context (e.g. by npm in case of package.json files).</simpara>
-</section>
-</section>
-<section xml:id="sec:JSON_Language_Extensions">
-<title>JSON Language Extensions</title>
-<simpara>Generally, our JSON support was implemented with generic JSON support in mind. However, for some types of JSON files (e.g. <literal>package.json</literal> files) we provide custom behavior to better assist the user. This includes custom JSON validators and resource description strategies that only apply to certain types of JSON files. In order to keep our JSON implementation independent from N4JS-specific code, these concerns are separated using an Eclipse Extension Point. In the headless case, extension also need to be registered manually via the <literal>JSONExtensionRegistry</literal>. In the following we present the different aspect in which the JSON language can be extended.</simpara>
-<section xml:id="sec:JSON_Validator_Extensions">
-<title>JSON Validator Extensions</title>
-<simpara>Via the JSON validator extensions (cf. <literal>IJSONValidatorExtension</literal>), other bundles can register JSON validator extensions that introduce domain-specific validation for specific types of JSON files.</simpara>
-<section xml:id="sec:File_Specitic_Validator_Extensions">
-<title>File-Specific Validator Extensions</title>
-<simpara>For every JSON resource that is validated, all registered JSON validator extensions are executed. For a validator extension to be specific to a certain type of file, one may override the Xtext method <literal>isResponsible</literal> which checks whether a validator applies on a per resource basis.</simpara>
-</section>
-<section xml:id="sec:JSON_Declarative_JSON_Validator_Extensions">
-<title>Declarative JSON Validator Extensions</title>
-<simpara>In addition to Xtext’s <literal>@Check</literal> methods, we provide an annotation <literal>@CheckProperty</literal> that allows to declare JSON-specific check methods that only apply to certain property paths of a JSON document. The <literal>@CheckProperty</literal> annotation can only be used when inheriting from the <literal>AbstractJSONValidatorExtension</literal> class. The following example outlines its usage:</simpara>
-<programlisting language="java" linenumbering="unnumbered">(...)
-@CheckProperty(propertyPath = "prop1")
-public void checkProperty(JSONValue propertyValue) {
- // validate JSONValue for top-level property 'prop1'
-}
-
-@CheckProperty(propertyPath = "nested.prop2")
-public void checkNestedProperty(JSONValue propertyValue) {
- // validate JSONValue for the nested property 'nested.prop2'
-}
-(...)</programlisting>
-<simpara>The examples illustrates how property-check-method can be declared. In a JSON document the first check method will only be invoked for the JSON value that is set for top-level property <literal>prop1</literal>. The second check method is invoked for the nested property <literal>prop2</literal> of the object that is set for the top-level property <literal>prop2</literal>.</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- "prop1": 1, // checkProperty applies
- "nested": {
- "prop2": 2 // checkNestedProperty applies
- }
-}</programlisting>
-<simpara>When inheriting from the <literal>AbstractJSONValidatorExtension</literal>, the usual <literal>addIssue</literal> methods may be used in order to issue validation messages. Furthermore, the issue codes that are being used for the messages may originate from the bundle that hosts the validator extension.</simpara>
-</section>
-</section>
-<section xml:id="_json-resource-description-strategy">
-<title>JSON Resource Description Strategy</title>
-<simpara>Via JSON resource description extensions (cf. <literal>IJSONResourceDescriptionExtension</literal>), other bundles can define a custom resource description strategy for specific types of JSON files. As a consequence, these extensions define what information on the contents of a JSON file is stored in the Xtext index (cf. <literal>IResourceDescriptions</literal>).</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_jsdoc">
-<title>JSDoc</title>
-<warning>
-<simpara>This chapter may be outdated.</simpara>
-</warning>
-<section xml:id="sec:Design_Rationale" role="language-n4js">
-<title>Design Rationale</title>
-<simpara>JSDoc parser provides general API for parsing and obtaining information embedded in comments. This may have low significance for N4JS itself but is essential when working with JS dialects (e.g. vanilla JS) that use JSDoc comments for enrich given dialect with semantic information. Anticipated uses may include: - type information extraction when importing external code - validation of links between commented fragments - supporting markup for documentation</simpara>
-<note>
-<simpara>Although current focus is on migration process we want to provide general solution that can be customized for given use cases</simpara>
-</note>
-<section xml:id="_general-design">
-<title>General Design</title>
-<simpara>When using the API client has to create instance of DocletParser and configure it with <emphasis>LienTag</emphasis>s and <emphasis>InLineTag</emphasis>s that are to be used.</simpara>
-<simpara>LineTags can depend on InlineTags (e.g. InlineTg in description of parameters of the LineTag). API provides support for that but client has to configure this.</simpara>
-<figure xml:id="fig:cd_JSDocParserAPI" role="center">
-<title>JSDoc Parser API (without model)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/23_jsdoc/images/cd_JSDocParserAPI.svg"/>
-</imageobject>
-<textobject><phrase>cd JSDocParserAPI</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Initiated DocletParser can be used to parse <emphasis>String</emphasis> containing given JSDoc comment.Based on provided <emphasis>ITagDefinition</emphasis>s parser will parse input string and return JSDoc DOM AST (see fig. XX with ecore diagram). By querying tree structure client can obtain information extracted form parsed input String.</simpara>
-<figure xml:id="fig:cd_JSDocModel" role="center">
-<title>JSDoc AST/DOM Model</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/23_jsdoc/images/cd_JSDocModel.svg"/>
-</imageobject>
-<textobject><phrase>cd JSDocModel</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The root of the this AST is the Doclet. The doclet itself contains some content (as it is a Composite containing ContentNodes), usually Description and an arbitrary number of LineTags. LineTags are created by custom ITagDefinition implementations that extend AbstractLineTagDefinition. They contain the title and an arbitrary number of values, stored in a map. These values are Composite nodes as well, containing tag specific content. E.g., the parameter tag will create the values for the parameter type, the parameter name, and the description. Description (in LineTags as well as in doclet itself) is free text with optional InlineTags. InlineTags are created by custom ITagDefinition that extends AbstractInlineTagDefinition. In general tag values are designed as a comprise between a very general tree (basically containing only text nodes) and a structured typed tree (containing type expressions etc.). Although it should be possible to model a tag value by only using Text nodes, some special typed nodes are provided for sake of simplicity (and probably performance). E.g., TypeReferences are modeled using a typed node, in order to simplify external handling of these references (for type analysis, and refactorings such as renaming a type). New typed nodes will probably be introduced (see below). Markers can be attached to nodes for internal purposes. E.g., a marker can be used to distinguish different syntax versions of defining an array (<literal>String[]</literal> vs. <literal>Array<String></literal>).Literals can be used to simplify rewriting. That is, they can contain information on line breaks, JSDoc line prefixes etc., which are not needed for the semantics of a tag, but only for the syntax (not used yet). Also, each node contains a position for simplifying rewriting.</simpara>
-<figure xml:id="fig:cd_JSDocParserAndModel" role="center">
-<title>JSDoc Parser and Model</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/23_jsdoc/images/cd_JSDocParserAndModel.svg"/>
-</imageobject>
-<textobject><phrase>cd JSDocParserAndModel</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:Type_Expressions">
-<title>Type Expressions</title>
-<simpara>Type expressions are are not handled by JSDoc Parser by itself as instances of the grammars are use case specific, e.g. for migration purposes grammar for type expressions used in migration process is specific to the in question therefore specific type expressions parser will be provided separately.DocLetParser by default can only extract String representing given type expression, parsing and interpreting it stays in responsibility of given tag implementation provided by the client.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_docexporter">
-<title>DocExporter</title>
-<warning>
-<simpara>This chapter may be outdated.</simpara>
-</warning>
-<simpara>The DocExporter exports JavaDoc from source files to adoc files.
-In particular it combines information about methods with tests in order to create specification documents.</simpara>
-<section xml:id="sec:Specification_Exporter">
-<title>Specification Exporter</title>
-<simpara>The specification exporter creates and merges artifacts.
-<link linkend="fig:api_test_spec">Fig. API Test Spec</link> sketches the relation between API (i.e., n4jsd files with classifiers),
-tests (i.e., N4JS test classes and methods), and specification (Documentation with JSDOC markers).</simpara>
-<figure xml:id="fig:api_test_spec" role="center">
-<title>Component/Class pseudo diagram: Relation API, Tests and Specification</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/24_docexporter/images/api_test_spec.svg"/>
-</imageobject>
-<textobject><phrase>api test spec</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><link linkend="fig:cd_jsdocreader">Fig. Exporter</link> shows the classes that read and analyze Java source documentation.</simpara>
-<figure xml:id="fig:cd_jsdocreader" role="center">
-<title>Java reader classes</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/24_docexporter/images/cd_jsdocreader.svg"/>
-</imageobject>
-<textobject><phrase>cd jsdocreader</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><link linkend="fig:cd_adocexporter">Fig. Exporter</link> shows the content classes of the exporter that contain the generated documentation contents.</simpara>
-<figure xml:id="fig:cd_adocexporter" role="center">
-<title>Exporter content classes</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/24_docexporter/images/cd_adocexporter.svg"/>
-</imageobject>
-<textobject><phrase>cd adocexporter</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><link linkend="fig:cd_docexporter_model">Fig. DocExporter Model</link> shows the model, which may be used for other doc exporters as well.</simpara>
-<figure xml:id="fig:cd_docexporter_model" role="center">
-<title>Exporter model classes</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/24_docexporter/images/cd_docexporter_model.svg"/>
-</imageobject>
-<textobject><phrase>cd docexporter model</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-</chapter>
-<chapter xml:id="_rename-refactoring">
-<title>Rename Refactoring</title>
-<simpara>The rename refactoring operation is implemented based on current Xtext’s rename refactoring implementation. However, lots of customization have been done in order to make Rename Refactoring work for N4JS. In order to understand N4JS customization, it is imperative to understand how Xtext implements rename refactoring. In this chapter, we will focus on Xtext’s architecture for rename refactoring. Additionally, we will point to the components that have been customized for N4JS.</simpara>
-<section xml:id="_rename-refactoring-ui-interaction">
-<title>Rename Refactoring UI interaction</title>
-<simpara>Xtext’s implementation allows rename refactoring be in either one of two modes (1) Direct refactoring mode (3) Refactoring with dialog mode. Diagram <link linkend="fig:rename_refactoring_communication_diagram_part1">Direct Rename Refactoring UI interaction</link> shows the UI interaction in <emphasis>direct refactoring mode</emphasis>.</simpara>
-<informalfigure xml:id="fig:rename_refactoring_communication_diagram_part1" role="center">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/25_renameRefactoring/images/rename_refactoring_communication_diagram_part1.svg"/>
-</imageobject>
-<textobject><phrase>title-"Direct Rename Refactoring UI interaction"</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>In this diagram, the classes in yellow are customized by N4JS implementation to handle N4JS-specific characteristics.</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>DefaultRenameElementHandler</literal>: Our custom N4JS implementation converts the selected element to be renamed into its corresponding TModule element.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>ILinkedPositionGroupCalculator</literal>: This class is responsible for calculating locations of names to be changed during linked edit mode. We need to provide a custom N4JS implementation to handle composed elements.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>RenameElementProcessor</literal>: We need to provide a custom N4JS implementation to add N4JS-specific validation of conditions, e.g. checking name conflicts etc.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The key class for creating updates of a declaration and its associated references is <literal>RenameElementProcessor</literal>. In the following section, we will see how this class interacts with other classes to achieve this.</simpara>
-</section>
-<section xml:id="_renameelementprocessor-interaction">
-<title>RenameElementProcessor interaction</title>
-<simpara>Diagram <link linkend="fig:rename_refactoring_communication_diagram_part2">RenameElementProcessor interaction</link> shows the interaction of <literal>RenameElementProcessor</literal> and other classes to create changes for both declaration and references during rename refactoring.</simpara>
-<informalfigure xml:id="fig:rename_refactoring_communication_diagram_part2" role="center">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/25_renameRefactoring/images/rename_refactoring_communication_diagram_part2.svg"/>
-</imageobject>
-<textobject><phrase>title-"RenameElementProcessor interaction"</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<simpara>As seen in the diagram, there are two stages of creating updates:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Creating updates for declaration is done by <literal>IRenameStrategy</literal> and</simpara>
-</listitem>
-<listitem>
-<simpara>Creating updates for references is done by <literal>ReferenceUpdateDispatcher</literal>. <literal>ReferenceUpdateDispatcher</literal> in turn delegates the finding of references to <literal>IReferenceFinder</literal>.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The text edits for changing the definition and the references are accumulated by an <literal>IRefactoringUpdateAcceptor</literal>.</simpara>
-<simpara>The classes in yellow are customized by N4JS implementation.</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>IRenameStrategy</literal>: the custom N4JS implementation creates updates for constituent members of composed elements.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>IReferenceFinder</literal>: the custom N4JS implementation used for finding references of a declaration.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>RefactoringCrossReferenceSerializer</literal>: custom N4JS implementation to retrieve the updated name for cross references. For some unknown reason, the default implementation does not work correctly.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</chapter>
-<chapter xml:id="chap:flowgraphs">
-<title>Flow Graphs</title>
-<section xml:id="sec:flowgraphs_overview" role="language-n4js">
-<title>Flow graphs overview</title>
-<simpara>In this chapter, the control and data flow analyses are introduced.
-Since not all AST elements are relevant for the control or data flow analyses, a new marker class is introduced called <literal>ControlFlowElement</literal>.
-All AST elements which are part of the control flow graph implement this class.
-The term control flow is abbreviated as <emphasis>CF</emphasis> and hence <literal>ControlFlowElement</literal>s are abbreviated as <emphasis>CF elements</emphasis>.</simpara>
-<simpara></simpara>
-<sidebar>
-<simpara><link xl:href="https://github.com/eclipse/n4js/issues/120"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #120</link></simpara>
-</sidebar>
-<simpara>The following picture shows the control flow graph of the function <literal>f</literal>.</simpara>
-<figure>
-<title>Control flow graph of a simple function</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/30_flowgraphs/images/cfg_for_loop.png"/>
-</imageobject>
-<textobject><phrase>cfg for loop</phrase></textobject>
-</mediaobject>
-</figure>
-<section xml:id="_internal-graph">
-<title>Internal graph</title>
-<simpara>Every <emphasis>internal graph</emphasis> refers to a single <emphasis>control flow container</emphasis>.
-The graph consists of <emphasis>nodes</emphasis> and <emphasis>edges</emphasis>, where the edges are instances of <literal>ControlFlowEdge</literal>, and nodes are instances of <literal>Node</literal>.
-Additionally, a so called <emphasis>complex node</emphasis> is used to group nodes that belong to the same CF element.</simpara>
-<variablelist>
-<varlistentry>
-<term>Internal graph</term>
-<listitem>
-<simpara>Control flow graphs are created based on the AST elements.
-Nevertheless, a fine-grained abstraction is used that is called <emphasis>internal graph</emphasis>.
-The internal graph reflects all control flows and data effects that happen implicitly and are part of the language’s semantics.
-For instance, the for-of statement on iterable objects forks the control flow after invoking the <literal>next()</literal> method.
-This is done implicitly and not part of the written source code.
-Moreover, this invocation could cause side effects.
-These control flows and effects are reflected using the internal graph.
-To implement analyses that refer to AST elements, an API for flow analyses is provided which hides the internal graph and works with AST elements only.
-In the following, the term <emphasis>control flow graph</emphasis> refers to the internal graph.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Control flow container</term>
-<listitem>
-<simpara>At several places in the AST, an execution of statements or elements can happen.
-Obviously, statements can be executed in bodies of methods or function expressions.
-In addition, execution can also happen in field initializers or the <literal>Script</literal> itself.
-Since all these AST elements can contain executable control flow elements (CF elements), they thus contain a control flow graph.
-In the following, these AST elements are called <emphasis>control flow containers</emphasis> or CF containers.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Nodes</term>
-<listitem>
-<simpara>Nodes represent complete CF elements or parts of them.
-For instance, simple CF elements like a <literal>break</literal> statement are represented using only one node.
-Regarding more complex CF elements that introduce a more complex control flow, due to e.g. nested expressions, several nodes represent one CF element.
-All nodes of a single CF element are grouped within a complex node.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Edges</term>
-<listitem>
-<simpara>Edges reference a start and an end node which reflects a forward control flow direction, which is in the following called forward traverse direction.
-Traversing from end to start of an edge is thus called backward traverse direction.
-The so called <emphasis>next node</emphasis> is either the end node in context of forward, or the start node in context of backward traverse direction.
-Edges also reflect the reason of the control flow using a control flow type.
-The default control flow type is called <literal>Successor</literal> and such edges connect two ordinary subsequent nodes.
-Other types like <literal>Return</literal> or <literal>Break</literal> indicate control flow that happens due to return or break statements.
-A special control flow type is <literal>Repeat</literal> that indicates the entry of a loop body.
-This edge is treated specially when traversing the control flow graph to avoid infinitive traversals of loops.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Complex node</term>
-<listitem>
-<simpara>The complex node always has a single entry and exit node, no matter the control flow it causes.
-For instance, although the for-statement can contain various control flows among its nested CF elements, its complex node still has a single entry and exit node.
-This simplifies concatenating subsequent complex nodes, since only their exit nodes have to be connected to the following entry node.
-Aside from exit and entry node, a complex node usually contains additionally nodes to represent the CF element.
-These nodes are connected by control flow edge so that their control flow lies within complex node.
-However, regarding nested CF elements, the control flow leaves and re-enters a complex node.
-To specify which CF element is nested, a delegating node (<literal>DelegatingNode</literal>) is created that points to the nested CF element.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Consider that source code elements can be nested like expressions that have sub-expressions as in <literal>1 + 2 * 3</literal>.
-Also statements can contain other statements like in <literal>if (true) return;</literal>.
-The design of the control flow graph deals with this nesting by mapping CF elements to several nodes.
-All nodes of one CF element are aggregated into the <emphasis>complex node</emphasis>.</simpara>
-<figure xml:id="img:internalGraph">
-<title>The source code of <literal>1+2</literal> creates an internal graph of three complex nodes to deal with nested integer literals</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/30_flowgraphs/images/internalGraph.png"/>
-</imageobject>
-<textobject><phrase>internalGraph</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The example in the <link linkend="img:internalGraph">figure above</link> shows the internal graph produced by the source code <literal>1+2</literal>.
-Additionally, a simpler version of the internal graph is shown (called <emphasis>User Graph View</emphasis>), with which client analyses deal.
-The user graph view is only a view on the internal graph, but does not exist as an own instance.
-In the figure, the nesting of the integer literals becomes obvious:
-The control flow edges of delegating nodes targets entry nodes of different CF elements.
-Also, there are CF edges from the exit nodes of these nested CF elements to return the control flow.</simpara>
-<figure xml:id="img:cn_for_stmt">
-<title>Complex Node of for statement</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/30_flowgraphs/images/cn_for_stmt.png"/>
-</imageobject>
-<textobject><phrase>cn for stmt</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>In the <link linkend="img:cn_for_stmt">above figure</link>, the complex node of the for statement is shown.
-The details of the complex nodes of the nested CF elements (such as the initializer or the body statement) are omitted.
-The figure displays the control flow fork after the condition and also shows the <emphasis>Repeat</emphasis> edge that targets the for body.
-The node called <emphasis>Catch Node</emphasis> is used in situations when there are jumping control flows introduced for instance by a continue statement.
-The catch will will then be the target of an control flow edge that starts at the continue statement.</simpara>
-<simpara>The graph of nodes and edges is constructed in the following order.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>First, for every CF element a complex node and all its nodes are created.
-Also, the nodes within the complex node are connected according to their control flow behavior.</simpara>
-</listitem>
-<listitem>
-<simpara>Second, all subsequent complex nodes are connected by connecting their exit and entry nodes.
-Moreover, nested complex nodes are connected by interpreting the delegating nodes.</simpara>
-</listitem>
-<listitem>
-<simpara>Third, jumping control due to <literal>return</literal>, <literal>throw</literal>, <literal>break</literal> or <literal>continue</literal> statements is computed.
-This is done by first deleting the successor edge of the jumping statement and introducing a new control flow edge that ends at the jump target.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_optimizations">
-<title>Optimizations</title>
-<simpara>The internal graph contains many nodes to simplify the graph construction.
-However, these nodes carry no relevant information when traversing the graph.
-Consequently, in an optimization step, they are removed from the graph for performance reasons.</simpara>
-<simpara>A node removal for a node <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>n</mi><mn>2</mn></msub></math> is done by replacing the path <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>n</mi><mn>1</mn></msub><mo>-</mo><mo>></mo><msub><mi>n</mi><mn>2</mn></msub><mo>-</mo><mo>></mo><msub><mi>n</mi><mn>3</mn></msub></math> by the new path <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>n</mi><mn>1</mn></msub><mo>-</mo><mo>></mo><msub><mi>n</mi><mn>3</mn></msub></math>.
-These removals are done for delegating nodes that only have one incoming and one outgoing edge.</simpara>
-<simpara>A second kind but similar optimization reduces the number of helper nodes that are used as entry nodes.
-In case a complex nodes consists only of exactly one entry and one exit node, both of these nodes are collapsed into one node.
-This remaining node then is the representing node of the AST element.</simpara>
-</section>
-<section xml:id="_api-for-client-analyses">
-<title>API for client analyses</title>
-<simpara>To implement client analyses based on the control flow graph, the three classes <literal>GraphVisitor</literal>, <literal>GraphExplorer</literal> and <literal>BranchWalker</literal> are provided.
-They provide the means to visit CF elements in a control flow graph and also to traverse single control flow paths.
-The method <literal>N4JSFlowAnalyses#analyze</literal> can execute several client analyses in one run to maintain scalability.</simpara>
-<section xml:id="_mapping-from-internal-to-ast-elements">
-<title>Mapping from internal to AST elements</title>
-<simpara>The API classes work with AST elements such as <literal>ControlFlowElement</literal> instead of the internally used graph classes <literal>ComplexNode</literal>, <literal>Node</literal> or <literal>ControlFlowEdge</literal>.
-The mapping from internal classes to AST elements is done in the <literal>GraphVisitor</literal> class.</simpara>
-<simpara>Note that the control flow graph has the following properties:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>ExpressionStatement</literal>s are not represented.
-Instead, only their expressions are represented.
-Nevertheless, the API can deal with calls that refer to expression statements, e.g. when requesting their successors.</simpara>
-</listitem>
-<listitem>
-<simpara>Control statements are also not represented in the graph, but can also be used in calls to the API.
-The reason is, that it is unclear when a control statement (e.g. a for loop) is visited exactly.</simpara>
-</listitem>
-<listitem>
-<simpara>Since a <literal>FlowEdge</literal> which connects two <literal>ControlFlowElement</literal>s can represent multiple internal edges, it can have multiple <literal>ControlFlowType</literal>s.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_graph-visitor">
-<title>Graph visitor</title>
-<simpara>Graph visitors traverse the control flow graphs of every CF container of a script instance in the following two traverse directions:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis>Forward</emphasis>: from the container’s start to all reachable CF graph elements.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Backward</emphasis>: from the container’s end to all reachable CF graph elements.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>In each traverse direction, the graph visitor visits every reachable CF element and edge.
-Note that neither empty statements nor control statements are part of the control flow graph.
-The order of visited CF elements is related to either a breadth or a depth search on the CF graph.
-However, no specific order assumptions are guaranteed.</simpara>
-<figure>
-<title>The CF elements <literal>"loop"</literal> and <literal>"end"</literal> are dead code and displayed in grey.</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/30_flowgraphs/images/deadcode.png"/>
-</imageobject>
-<textobject><phrase>deadcode</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="_graph-explorer">
-<title>Graph explorer</title>
-<simpara>Graph visitors can request a <emphasis>graph explorer</emphasis> to be activated under specific conditions related to the client analysis.
-A graph explorer is the start point to analyze control flow branches.
-The first control flow branches is started directly at the graph explorer’s creation site, but of course this first branches might fork eventually.
-The graph explorer keeps track of all forked branches that originate at its activation site.
-It also provides the means to join previously forked branches again.</simpara>
-</section>
-<section xml:id="_branch-walker">
-<title>Branch walker</title>
-<simpara>With every graph explorer, a branch walker is created that traverses the control flow graph beginning from the activation site of the graph explorer.
-On every such branch, the two visit methods of CF elements and edges respectively, are called in the order of the traverse direction.
-Every time the branch forks, the fork method of the branch walker is invoked and creates another branch walker which will continue the traversal on the forked branch.
-The fork method can be used to copy some path data or state to the newly forked branch walker.
-Note that every edge is always followed by the branch walker except for repeat edges which are followed exactly twice.
-The reason to follow them twice is that first, following them only once would hide those control flows that re-visit the same CF elements due to the loop.
-Second, following them more than twice does not reveal more insights, but only increases the number of branches.
-When control flow branches merge again, for instance at the end of an <literal>if</literal>-statement, two or more branch walkers are merged into a new succeeding one.
-The graph explorer provides the means to do this.
-In case a CF element has no next elements, the branch walker terminates.</simpara>
-</section>
-<section xml:id="_example-1-compute-string-for-each-path">
-<title>Example 1: Compute string for each path</title>
-<simpara>Let’s assume that we want to compute all control flow branches of a function and use the client API for that.
-The function <literal>f()</literal> in the following code snippet has four control flow branches: <literal>1 → 2</literal>, <literal>→ 3 →</literal>, <literal>→ 4 →</literal> and <literal>5</literal>.</simpara>
-<formalpara>
-<title>Function <literal>f()</literal> has four control flow branches.</title>
-<para>
-<screen>function f() {
- 1;
- if (2)
- 3;
- else
- 4;
- 5;
-}</screen>
-</para>
-</formalpara>
-<simpara>To compute these control flow branches, the class <literal>AllBranchPrintVisitor</literal> extends the <literal>GraphVisitor</literal>.
-Already in the method <literal>initializeMode()</literal> a graph explorer is activated.
-Note that the method <literal>requestActivation()</literal> can be understood as a <literal>addListener</literal> method for a listener that listens to visit events on nodes and edges.
-Immediately after the activation request, the first branch walker is created in the method <literal>firstBranchWalker()</literal>.</simpara>
-<simpara>The first visited CF element of the branch walker will then be the expression <literal>1</literal>.
-It is formed into a string and added to the variable <literal>curString</literal>.
-After expression <literal>1</literal>, the flow edge from <literal>1</literal> to <literal>2</literal> is visited.
-This will concatenate the string <literal>→</literal> to the path string.
-Variable <literal>curString</literal> will eventually hold the branch string like <literal>1 → 2</literal>.
-Since the control flow forks after <literal>2</literal>, the method <literal>forkPath()</literal> is called and creates two new instances of a branch walker.
-These new instances succeed the the first branch walker instance and each traverses one of the branches of the <literal>if</literal>-statement.
-When the <literal>if</literal>-statement is passed, these two branches are merged into a new succeeding branch walker.
-After all branch walkers are terminated, the graph explorer and graph visitor are also terminated.
-The method <literal>getBranchStrings()</literal> collects all four computed strings from the variable <literal>curString</literal> of all branch walkers.</simpara>
-<formalpara>
-<title>Implementation of a graph visitor that computes all control flow paths</title>
-<para>
-<screen>class AllBranchPrintVisitor extends GraphVisitor {
- protected void initializeMode(Mode curDirection, ControlFlowElement curContainer) {
- super.requestActivation(new AllBranchPrintExplorer());
- }
-
- class AllBranchPrintExplorer extends GraphExplorer {
- class AllBranchPrintWalker extends BranchWalker {
- String curString = "";
-
- protected void visit(ControlFlowElement cfe) {
- curString += cfe.toString();
- }
-
- protected void visit(FlowEdge edge) {
- curString += " -> ";
- }
-
- protected AllBranchPrintWalker forkPath() {
- return new AllBranchPrintWalker();
- }
- }
-
- protected BranchWalker joinBranches(List<BranchWalker> branchWalkers) {
- // TODO Auto-generated method stub
- return null;
- }
-
- protected BranchWalkerInternal firstBranchWalker() {
- return new AllBranchPrintWalker();
- }
- }
-
- List<String> getBranchStrings() {
- List<String> branchStrings = new LinkedList<>();
- for (GraphExplorerInternal app : getActivatedExplorers()) {
- for (BranchWalkerInternal ap : app.getAllBranches()) {
- AllBranchPrintWalker printPath = (AllBranchPrintWalker) ap;
- branchStrings.add(printPath.curString);
- }
- }
- return branchStrings;
- }
-}</screen>
-</para>
-</formalpara>
-</section>
-<section xml:id="_path-quantor">
-<title>Path quantor</title>
-<simpara>Graph explorers are typically used to reason on all branch walkers that start at a specific location.
-For instance, such a reasoning might determine whether some source element is reachable or whether a variable is used or not.
-To simplify this, quantors are provided.
-Since branch walkers originating from a single activation point can fork, the reasoning has to include all these forked branch walkers.
-Hence, graph explorers are instantiated using a quantor which can be either <emphasis>For All</emphasis>, <emphasis>At Least One</emphasis> OR <emphasis>None</emphasis> that refers to all branches.
-After all branch walkers of an explorer are terminated, the explorer is regarded as either passed or failed.
-Paths also can be aborted manually using the methods <literal>pass()</literal> or <literal>fail()</literal>.
-When <emphasis>pass</emphasis> or <emphasis>fail</emphasis> are used, the graph explorer might be terminated in the following cases:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If the quantor of the graph explorer is <emphasis>For All</emphasis>, and <literal>fail()</literal> is called on a branch walker.</simpara>
-</listitem>
-<listitem>
-<simpara>If the quantor of the graph explorer is <emphasis>At Least One</emphasis>, and <literal>pass()</literal> is called on a branch walker.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Additionally, a graph explorer can be aborted manually by canceling all its branches.</simpara>
-</section>
-</section>
-<section xml:id="_control-flow-analyses">
-<title>Control flow analyses</title>
-<section xml:id="_dead-code-analysis">
-<title>Dead code analysis</title>
-<simpara>The dead code analysis uses the graph visitor in all four modes and collects all visited CF elements.
-The collected CF elements are saved separately for every mode.
-After the graph visitor is terminated, the unreachable CF elements are computed like follows:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>CF elements, that are collected during forward and catch block mode are reachable.</simpara>
-</listitem>
-<listitem>
-<simpara>CF elements, that are collected during islands mode are unreachable.</simpara>
-</listitem>
-<listitem>
-<simpara>CF elements, that are <emphasis>only</emphasis> collected during backward mode, are also unreachable.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>In a later step, the unreachable elements are merged into unreachable text regions that are used for error markers.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="sec:dataflow" role="language-n4js">
-<title>Dataflow</title>
-<simpara></simpara>
-<sidebar>
-<simpara><link xl:href="https://github.com/eclipse/n4js/issues/331"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #331</link>
-<link xl:href="https://github.com/eclipse/n4js/issues/464"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #464</link></simpara>
-</sidebar>
-<section xml:id="_dataflow-graph">
-<title>Dataflow graph</title>
-<simpara>The data flow graph provides means to reason about <emphasis>symbols</emphasis>, <emphasis>effects</emphasis>, <emphasis>data flow</emphasis>, <emphasis>aliases</emphasis> and <emphasis>guards</emphasis> in the control flow graph.
-The main classes of the data flow API are <literal>DataflowVisitor</literal> and <literal>Assumption</literal>.</simpara>
-<variablelist>
-<varlistentry>
-<term>Symbol</term>
-<listitem>
-<simpara>Symbols represent a program variable in the sence that it represents all AST elements, that bind to the same variable declaration (according to scoping).
-The terms <emphasis>symbol</emphasis> and <emphasis>variable</emphasis> are used synonymously.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Effect</term>
-<listitem>
-<simpara>Effects are reads, writes and declarations of symbols.
-For instance, a typical CF element with a write effect is an assignment such as <literal>a = null;</literal>.
-Every effect refers to a single symbol and graph node.
-The following effects are provided:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis>Declaration</emphasis>: is the declaration of a variable.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Write</emphasis>: is the definition of a variable’s value, which is typically done with an assignment.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>Read</emphasis>: is the read of a variable’s value, which could happen when passing a variable as an argument to a method call.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>MethodCall</emphasis>: is the call of a property method of a variable.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Note that the term <emphasis>value use</emphasis> means either write or method call of a variable.
-The term <emphasis>value definition</emphasis> means that a variable is written.</simpara>
-<variablelist>
-<varlistentry>
-<term>Data flow</term>
-<listitem>
-<simpara>The term data flow is used for assignments of all kind.
-For instance, the assigments <literal>a = b</literal>, <literal>a = 1</literal>, <literal>a = null</literal> or even <literal>for (let [a] of [[0],[undefined]]);</literal> are data flows.
-The data is always flowing from the right hand side to the left hand side.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Alias</term>
-<listitem>
-<simpara>Due to data flow, other symbols can get important for an analysis.
-For instance, the data flow <literal>a = b</literal> makes <literal>b</literal> important when reasoning about <literal>a</literal> since the value of <literal>b</literal> is assigned to <literal>a</literal>.
-In the API is <literal>b</literal> therefore called an alias of <literal>a</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Guard</term>
-<listitem>
-<simpara>Guards are conditions that appear in e.g. <literal>it</literal>-statements.
-For instance, a typical guard is the null-check in the following statement: <literal>if (a == null) foo();</literal>.
-For every CF element, guards can hold either <emphasis>always</emphasis>, <emphasis>never</emphasis> or <emphasis>sometimes</emphasis>.
-Note that the null-check-guard always holds at the method invocation <literal>foo();</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>DataflowVisitor</literal></term>
-<listitem>
-<simpara>The class <literal>DataflowVisitor</literal> provides means to visit all code locations where either effects happen or guards are declared.
-For instance, when a variable is written, the callback method <literal>DataflowVisitor#visitEffect(EffectInfo effect, ControlFlowElement cfe)</literal> gets called.
-In case a guard is declared, the callback method <literal>visitGuard(Guard guard)</literal> gets called.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Assumption</literal></term>
-<listitem>
-<simpara>The class <literal>Assumption</literal> provides means to track the data flow of a specific symbol from a specific code location.
-For instance, assumptions are used to detect whether the symbol <literal>s</literal> in the property access <literal>s.prop</literal> is or may be undefined.
-In this example, the assumption symbol is <literal>s</literal> and its start location is the property access.
-From there, the data flow of <literal>s</literal> is tracked in backwards traverse direction.
-Also, (transitive) aliases of <literal>s</literal> are tracked.
-In case a data flow that happens on <literal>s</literal> or its aliases, the callback method <literal>holdsOnDataflow(Symbol lhs, Symbol rSymbol, Expression rValue)</literal> is called.
-For every effect that affects <literal>s</literal> or one of its aliases, the callback method <literal>holdsOnEffect(EffectInfo effect, ControlFlowElement container)</literal> is called.
-And finally, for all guards that hold always/never at the start location regarding symbol <literal>s</literal>, the callback method <literal>holdsOnGuards(Multimap<GuardType, Guard> neverHolding, Multimap<GuardType, Guard> alwaysHolding)</literal> is called.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_dataflow-analyses">
-<title>Dataflow analyses</title>
-<section xml:id="_def-def-def-nothing-analysis">
-<title>Def→Def / Def→Nothing analysis</title>
-<simpara>A Def→Def analysis finds all defintions of a variable that are always a predecessor of another definition.
-Its result is a set of all obsolete definition sites.</simpara>
-<simpara>A Def→!Use analysis finds all definitions of a variable that are not followed by either a read or a method call.
-These definition are therefore obsolete and can be removed.</simpara>
-<simpara>Both of these analyses are performed in traverse direction <emphasis>Forward</emphasis>.</simpara>
-</section>
-<section xml:id="_def-use-decl-analysis">
-<title>Def|Use←Decl analysis</title>
-<simpara>A Def|Use←Decl analysis finds all preceding <emphasis>def</emphasis> or <emphasis>use</emphasis> sites of a declarations of a specific variable.
-The paths might contain other <emphasis>defs</emphasis> or <emphasis>uses</emphasis> of the same variable.
-In case such paths exists, the variable is used before it is declared.
-This analysis is done in traverse direction <emphasis>Backward</emphasis>.</simpara>
-<figure xml:id="img:usedBeforeDeclaredAnalysis">
-<title>Finding use or def sites can be done using the graph visitor in traverse direction <emphasis>Backward</emphasis>.</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/30_flowgraphs/images/usedBeforeDeclaredAnalysis.png"/>
-</imageobject>
-<textobject><phrase>usedBeforeDeclaredAnalysis</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>In the <link linkend="img:usedBeforeDeclaredAnalysis">above figure</link> a graph visitor would visit all CF elements.
-When it visits the declaration in line 8 (<literal>let w</literal>), it will activate a graph explorer (star 1 in the figure) for variable <literal>w</literal>.
-Now, the first branch walker <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>1</mn></msub></math> is created and walks the control in backward traverse direction.
-When <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>1</mn></msub></math> encounters the exit node of the <literal>if</literal>-statement, it will create two forked branches <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>2</mn></msub></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>3</mn></msub></math>.
-Now, <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>2</mn></msub></math> enters then the branch of the <literal>if</literal>-statement (star 2), while <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>3</mn></msub></math> traverses directly to the condition of the <literal>if</literal>-statement.
-Next, <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>2</mn></msub></math> visits the def site of variable <literal>w</literal> (star 3).
-This means, that there exist a def site of <literal>w</literal> before <literal>w</literal> was declared and hence, an error should be shown.
-Since there could exist more cases like this, neither the branch walker nor the graph explorer are terminated.
-When reaching star 4, the two branch walkers <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>2</mn></msub></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>3</mn></msub></math> are joined and the follow-up branch walker <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>4</mn></msub></math> is created.
-At star 5, the end the CF container is reached and the <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>4</mn></msub></math> will be terminated.
-After all branch walkers are terminated, the graph explorer for the declaration site of variable <literal>w</literal> is evaluated:
-All use or def sites, that were reachable should be marked with an error saying that the declaration has to be located before the use of a variable.</simpara>
-<simpara>Note this analysis is currently implemented as a control flow analysis since it does not rely on guards, aliases.
-Also, it only relies on local variables and hence does not need the symbols that are provided by the data flow API.</simpara>
-</section>
-</section>
-</section>
-</chapter>
-<chapter xml:id="sec:publish-npms-to-public">
-<title>Publish npms</title>
-<simpara>We publish npms located in the folder <literal>n4js-libs</literal> to the <link xl:href="registry.npmjs.org">public npm registry</link>. Specifically, the following npms are published:</simpara>
-<variablelist>
-<varlistentry>
-<term>Command line tools</term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara>n4js-cli</simpara>
-</listitem>
-<listitem>
-<simpara>n4js-mangelhaft-cli</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Runtime definition files</term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara>n4js-runtime-ecma402</simpara>
-</listitem>
-<listitem>
-<simpara>n4js-runtime-es2015</simpara>
-</listitem>
-<listitem>
-<simpara>n4js-runtime-esnext</simpara>
-</listitem>
-<listitem>
-<simpara>n4js-runtime-fetch</simpara>
-</listitem>
-<listitem>
-<simpara>n4js-runtime-html5</simpara>
-</listitem>
-<listitem>
-<simpara>n4js-runtime-node</simpara>
-</listitem>
-<listitem>
-<simpara>n4js-runtime-v8</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Mangelhaft</term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara>org.eclipse.n4js.mangelhaft</simpara>
-</listitem>
-<listitem>
-<simpara>org.eclipse.n4js.mangelhaft.assert</simpara>
-</listitem>
-<listitem>
-<simpara>org.eclipse.n4js.mangelhaft.reporter.console</simpara>
-</listitem>
-<listitem>
-<simpara>org.eclipse.n4js.mangelhaft.reporter.ide</simpara>
-</listitem>
-<listitem>
-<simpara>org.eclipse.n4js.mangelhaft.reporter.xunit</simpara>
-</listitem>
-<listitem>
-<simpara>org.eclipse.n4js.mangelhaft.runner.ide</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>In order to make sure that the npms work correctly with the <literal>n4js</literal> product, we need to integration test the interplay between the n4js products and the npms. Right now, we only focus on the interplay between the <literal>n4js</literal> headless compiler and npms. For integration tests, we publish the npms to a local npm registry which is provided by <link xl:href="https://www.verdaccio.org/docs/en/docker.html">verdaccio docker image</link> before executing the tests. When all integration tests are executed, we stop the local npm registry.</simpara>
-<section xml:id="sec:publish-npms-n4js-maven">
-<title>Publish n4js-libs to during maven build</title>
-<warning>
-<simpara>The NPMs are currently published using NumberFour’s internal build infrastructure in combination with extended integration tests. This needs to be changed in the future!</simpara>
-</warning>
-<simpara>This section describes how integration tests can use local npm registry during the test.
-All integration tests that require a local npm registry should be placed in the bundle <literal>org.eclipse.n4js.hlc.integrationtests</literal></simpara>
-<figure role="center">
-<title>Maven phases</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/40_publish_npms/images/publish_npm_in_mvn_workflow.svg"/>
-</imageobject>
-<textobject><phrase>publish npm in mvn workflow</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>During the maven build, three projects <literal>org.eclipse.n4js.external.libraries.update</literal>, <literal>org.eclipse.n4js.product.build</literal> and <literal>org.eclipse.n4js.hlc.integrations</literal> are built by maven in that order.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>During the phase <emphasis>process-classes</emphasis> of the <literal>org.eclipse.n4js.external.libraries.update</literal> build, the UpdateShippedCode MWE2 workflow is triggerd to compile n4js code of npms in n4js-lib. The phase <emphasis>process-classes</emphasis> was chosen because it must happen after the <literal>org.eclipse.n4js.external.libraries.update</literal> bundle has been compiled.</simpara>
-</listitem>
-<listitem>
-<simpara>During the <emphasis>verify</emphasis> phase of the <literal>org.eclipse.n4js.product.build</literal> build, the Maven <literal>exec-maven</literal> plugin calls the script <literal>n4js/releng/utils/scripts/publish-n4js-libs.sh</literal> to publish the npms in the n4js-lib to the <emphasis>staging npm registry</emphasis>. The URL of this staging npm registry must be configured before triggering maven build via the environment variable <literal>NPM_STAGING_REGISTRY</literal>. Note that the staging npm registry lives beyond the life of <literal>n4js-inhouse</literal> 's maven build and holds npms that are needed by the integration tests in the n4js-extended’s build.</simpara>
-</listitem>
-<listitem>
-<simpara>During the <emphasis>pre-integration-test</emphasis> phase of the <literal>org.eclipse.n4js.hlc.integrationtests</literal> bundle, the Maven <literal>antrun</literal> plugin starts a <emphasis>verdaccio</emphasis> docker container local npm registry at <literal><link xl:href="http://localhost:4873">http://localhost:4873</link></literal> via docker. Also in the very same phase, the Maven plugin <literal>exec-maven</literal> calls the script <literal>n4js/releng/utils/scripts/publish-n4js-libs.sh</literal> to publish the npms in the n4js-lib folder to the local registry <literal><link xl:href="http://localhost:4873">http://localhost:4873</link></literal>. The list of published npms is identical to that list above. Note that the npms are published with the <literal>dist-tag</literal> <emphasis>test</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara>During the <emphasis>integration-test</emphasis> phase of <literal>org.eclipse.n4js.hlc.integrationtests</literal>, the Maven <literal>failsafe</literal> plugin executes the integration tests. Here, the integration tests can pull the required npms from the local registry populated during the <emphasis>pre-integration-test</emphasis> above.</simpara>
-</listitem>
-<listitem>
-<simpara>In the <emphasis>pre-integration-test</emphasis> phase of <literal>org.eclipse.n4js.hlc.integrationtests</literal>, the Maven <literal>antrun</literal> plugins removes the <emphasis>verdaccio</emphasis> docker container.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</chapter>
-<appendix xml:id="sec:Hints">
-<title>Hints</title>
-<simpara>In this chapter, some tips and tricks regarding Eclipse, Xtend and Maven should be collected.</simpara>
-<section xml:id="sec:XtextInjection">
-<title>Xtext Injection</title>
-<simpara><xref linkend="fig:cd_XtextInjectors"/> shows different injectors used by Xtext
-and their relation to the injector of a custom language created with Xtext
-(in this example N4JS).</simpara>
-<figure xml:id="fig:XtextInjectors" role="center">
-<title>Xtext injectors and custom DSL injector</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/a02_hints/images/cd_XtextInjectors.svg"/>
-</imageobject>
-<textobject><phrase>cd XtextInjectors</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><emphasis role="strong">Injectors creation:</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>create 'SharedInjector'</simpara>
-<itemizedlist>
-<listitem>
-<simpara>create shared singletons</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>create (lazily) custom language injector</simpara>
-<itemizedlist>
-<listitem>
-<simpara>take singletons from shared injector</simpara>
-</listitem>
-<listitem>
-<simpara>add bindings from 'SharedModule'</simpara>
-</listitem>
-<listitem>
-<simpara>create own singletons</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-<simpara>Normally one injector is bound to one language.
-'ContributingModule' allows custom languages to contribute bindings to the
-shared state, effectively cross project boundaries.</simpara>
-<simpara>It must be noted that in case of N4JS tools there are multiple languages
-contributing / extending Xtext injector, which can be seen in figure
-<xref linkend="fig:cd_customInjectors"/></simpara>
-<figure xml:id="fig:cd_customInjectors" role="center">
-<title>Xtext injectors and custom DSL injector</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/a02_hints/images/cd_customInjectors.svg"/>
-</imageobject>
-<textobject><phrase>cd customInjectors</phrase></textobject>
-</mediaobject>
-</figure>
-<section xml:id="sec:DI_MultipleInjectors_Singletons">
-<title>Multiple Injectors and Singletons</title>
-<simpara>Every injector creates its 'ObjectGraph'. Having multiple Injectors in
-the system leads to multiple (disconnected) object graphs. For normal instances
-that is not an issue, but for scoped instances this causes problems.
-Most common issue happens with '@Singleton' instances that carry state.</simpara>
-<figure xml:id="fig:cd_SingletonDuplicate" role="center">
-<title>Xtext injectors and custom DSL injector</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/a02_hints/images/cd_SingletonDuplicate.svg"/>
-</imageobject>
-<textobject><phrase>cd SingletonDuplicate</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><xref linkend="fig:cd_customInjectors"/> shows situation in which both 'ChildInjector'
-and 'N4JSInjector' have their bindings for 'N4JSEclipseCore'. As a result those
-injectors will create their instance of core that is expected to be
-'@Singleton'. Additionally, this will be true for all its transitive
-dependencies.</simpara>
-<section xml:id="sec:DI_avoid_duplicate_singletons">
-<title>Avoiding duplicate singletons</title>
-<simpara>To avoid issue with duplicate singletons two distinct injectors should not
-have their bindings for singletons. Developer needs to decide where to
-define <emphasis role="strong">the only</emphasis> binding, and let one 'ObjectGraph' delegate to another.</simpara>
-<section xml:id="sec:DI_binding_in_shared">
-<title>Defining binding in the shared injector</title>
-<simpara>One approach is to define binding in the shared injector. Then in the injector
-of the custom language to delegate to the shared contribution.</simpara>
-<screen>/** Binds {@link IN4JSCore} */
-public class ContributingModule implements Module {
- @Override
- public void configure(Binder binder) {
- binder.bind(IN4JSCore.class).to(IN4JSEclipseCore.class);
- binder.bind(IN4JSEclipseCore.class).to(N4JSEclipseCore.class).in(SINGLETON);
- }
-}
-
-/** Delegates binding for {@link IN4JSCore} to the shared provider. */
-public class ContributingModule implements Module {
- public Provider<? extends IN4JSCore> bindIN4JSCore() {
- return Access.contributedProvider(N4JSEclipseCore.class);
- }
-}</screen>
-<simpara>Downside of this approach is in the shared injector itself.
-It does not allow for implicit bindings. This forces developer to declare
-bindings for <emphasis role="strong">all transitive</emphasis> dependencies of the main binding explicitly.
-Additionally, every custom language has to do it. These make shared injector
-the <emphasis>GodInjector</emphasis> that contains configuration for all custom languages,
-it is responsible for creating most objects in the system, and potentially
-exposes types from one language to another language where it might not be
-desired.</simpara>
-</section>
-<section xml:id="sec:DI_binding_in_custom">
-<title>Defining binding in the custom injector</title>
-<simpara>Other approach is to define binding in the injector for a custom
-language. Then let instances in the shared injector object graph to obtain
-singleton instances via custom language injector (which is stored on the
-custom language activator).</simpara>
-<screen>/** Does not bind {@link IN4JSCore} */
-public class ContributingModule implements Module {
- @Override
- public void configure(Binder binder) {
- // no core binding
- }
-}
-
-/** Binds {@link IN4JSCore}. */
-public class ContributingModule implements Module {
- public Class<? extends IN4JSCore> bindIN4JSCore() {
- return IN4JSEclipseCore.class;
- }
-}
-
-/** Some type used in shared injector object graph */
-public SomeSharedType{
-
- /** Obtain {@link IN4JSCore} form {@code N4JSInjector}. */
- private IN4JSCore getIN4JSCore() {
- return N4JSActivator
- .getInstance()
- .getInjector(ORG_ECLIPSE_N4JS_N4JS)
- .getInstance(IN4JSCore.class);
- }
-}</screen>
-<simpara>This approach also has downsides. In the 'SomeSharedType' that exists in the
-shared injector object graph we cannot inject 'IN4JSCore' as it is not
-known to the shared injector. Instead, we have to get the instance form the
-'N4JSInjector' manually. This requires developer to know whole (singleton)
-types structure
-defined in every custom language.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="sec:DI_Hints" role="language-n4js">
-<title>Dependency Injection Hints</title>
-<section xml:id="sec:DI_custom_bundle">
-<title>Use DI in custom bundle, use DI with extensions</title>
-<section xml:id="sec:DI_custom_bundle_problem">
-<title>Problem</title>
-<simpara>DI should be used in a custom bundle, i.e. a bundle not generated by Xtext.
-E.g., a new handler should be provided in its plugin, and this handler requires
-an injected instance. Example</simpara>
-<simpara>my.dsl.bundle.ui xtext generated</simpara>
-<simpara>my.dsl.bundle.sub.ui
-The following class is contained in my custom plugin:</simpara>
-<screen>class my.dsl.bundle.sub.ui.Handler {
- @Inject SomeDSLOrXtextSpecificType obj;
-}</screen>
-<simpara>The question is, how can obj of type be injected at this location?</simpara>
-</section>
-<section xml:id="sec:DI_custom_bundle_solution">
-<title>Solution</title>
-<simpara>First of all, to use DI in a type, the type instance itself must have been
-created via DI. This requires an injector which uses the same class loader as
-the type using the injector. This means that a new bundle needs its injector,
-created by an IExecutableExtensionFactory using the bundles' activator (plugin)
-singleton.</simpara>
-<simpara>This activator can extend the generated activator of a Xtext bundle. The
-following code can be used as a template, as long as no custom non-default
-bindings are to be added (in this case, have a look at the generated activator
-and override the methods configuring the injector):</simpara>
-<screen>public class my.dsl.bundle.sub.ui.Activator extends my.dsl.bundle.ui.MyDSLActivator {
- private static my.dsl.bundle.sub.ui.Activator INSTANCE;
-
- @Override
- public void start(BundleContext context) throws Exception {
- super.start(context);
- INSTANCE = this;
- }
-
- @Override
- public void stop(BundleContext context) throws Exception {
- INSTANCE = null;
- super.stop(context);
- }
-
- public static TypePopupActivator getInstance() {
- return INSTANCE;
- }
-}</screen>
-<simpara>Additionally, a custom 'AbstractGuiceAwareExecutableExtensionFactory' has to be
-implemented. This class then uses the new activator instance (this is required
-as bundles have their classloaders!)</simpara>
-<screen>public class my.dsl.bundle.sub.ui.SubExecutableExtensionFactory extends AbstractGuiceAwareExecutableExtensionFactory {
- @Override
- protected Bundle getBundle() {
- return my.dsl.bundle.sub.ui.Activator.getInstance().getBundle();
- }
-
- @Override
- protected Injector getInjector() {
- return my.dsl.bundle.sub.ui.Activator.getInstance().getInjector(MyDSLActivator.MY_LANGUAGE_GRAMMAR);
- }
-}</screen>
-<simpara>Now, we can use this extension factory in the plugin.xml of the sub bundle to
-let the handler be created via DI. E.g.</simpara>
-<screen>"org.eclipse.ui.handlers"&gt;
-<handler
-class="my.dsl.bundle.sub.ui.SubExecutableExtensionFactory:my.dsl.bundle.sub.ui.Handler"
-commandId="..."&gt;
-handler&gt;
-extension&gt;</screen>
-</section>
-</section>
-<section xml:id="sec:Access_Other_DSL_Injector">
-<title>How do I get the Guice Injector of my language?</title>
-<simpara>We have the use case to load a N4MF file inside the N4JS infrastructure to read
-out the project description and configure the qualified names and container
-visibility. I.e. we have to load another DSL in our current DSL infrastructure,
-in the use case to have a Xtext resource set available to load the N4MF file.
-Injecting the Xtext resource of the current DSL wouldn’t work as it has not the
-N4MF injection context. So in the following the ways how to access this
-injection context is described as extracted from
-<link xl:href="http://koehnlein.blogspot.de/2012/11/xtext-tip-how-do-i-get-guice-injector.html">this blog post</link>.</simpara>
-<section xml:id="sec:DSL_Injector_UI_context">
-<title>UI context</title>
-<simpara>To access another DSL injector in a UI DSL project just add a dependency to the
-UI project of the other DSL and then</simpara>
-<screen>MyClass myClass =
-TheOtherDSLActivator.getInstance().getInjector().get(MyClass.class)</screen>
-</section>
-<section xml:id="sec:DSL_Injector_Non_UI_context">
-<title>Non UI context but with injection context</title>
-<screen>@Inject IResourceServiceProvider.Registry serviceProviderRegistry;
-...
-MyClass myClass
-=
-serviceProviderRegistry.getResourceServiceProvider(URI.createFileURI(n4mfFileAbsolutePath)).get(MyClass.class)</screen>
-</section>
-<section xml:id="sec:DSL_Injector_Non_UI_non_injection_context">
-<title>Non UI context without injection context</title>
-<screen>@Inject IResourceServiceProvider.Registry serviceProviderRegistry;
-...
-MyClass
-myClass
-=
-IResourceServiceProvider.Registry.INSTANCE.getResourceServiceProvider(uri).get(MyClass.class);</screen>
-</section>
-</section>
-<section xml:id="sec:Cancel_Indicator">
-<title>How do I get cancel indicators in different contexts?</title>
-<simpara>Several factors contribute to responsiveness in the IDE, but here we focus in
-running jobs in the background and reacting to cancellation requests.</simpara>
-<simpara>The Eclipse Jobs API is recommended for potentially long-running tasks (other
-than incremental building, which has dedicated support). For example, the
-outline view is populated by a background job, running validations on the
-resource (and honoring cancellation requests initiated as for any job).</simpara>
-<simpara>Cancel indicators are a Xtext abstraction while Eclipse favors progress
-monitors, the latter including not only cancellation capability but also a
-callback mechanism to give feedback in the UI about intermediate progress.
-Cancel indicator can wrap a progress monitor.</simpara>
-<simpara>Cancel indicators come in two variants, depending on the source of cancellation
-events:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a resource becoming stale (usually as a result of editing sources) triggers
-cancellation. These cancel indicators can be obtained via
-'OutdatedStateManager', which itself is available via injection.</simpara>
-</listitem>
-<listitem>
-<simpara>cancel indicators associated to the UI, for example associated to an Eclipse
-job. Examples:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>for an outline view running in the background, an override of method
-'createRoot()' from 'DefaultOutlineTreeProvider' receives a UI-aware cancel
-indicator;</simpara>
-</listitem>
-<listitem>
-<simpara>for the transpiler, instances that carry cancel indicator are
-'IFileSystemAccess' and (in the future) 'IGenerator2'. To track the latter, see
-Eclipse bug 477068.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-<simpara>In general, whenever a resource is validated cancel indicator should be checked
-periodically. These checks are performed automatically via
-'MethodWrapperCancelable' before the (reflective) invocation of each validation
-method and therefore require no manual intervention, see
-'AbstractMessageAdjustingN4JSValidator'. However, that doesn’t help in case a
-single validation method ''takes too long''. To simplify those checks, utility
-'isCanceled()' of 'AbstractMessageAdjustingN4JSValidator' can be invoked.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="sec:Eclipse">
-<title>Eclipse</title>
-<section xml:id="sec:Show_Xtext_Index">
-<title>Show the current Xtext index</title>
-<simpara>Press the following keyboard shortcut in the running UI: <keycap>CTRL</keycap><?asciidoc-br?>
-<keycap>SHIFT</keycap> + <keycap>F3</keycap> (likely under Mac <keycap>CMD</keycap> + <keycap>SHIFT</keycap> + <keycap>F3</keycap>).</simpara>
-</section>
-<section xml:id="sec:Plugin_spy">
-<title>Plug-in spy</title>
-<simpara>Not special for Xtext but very helpful do identify which class implements a UI
-concept, for example, if you want to know which class implements the Open Model
-Element dialog just press <keycap>CTRL</keycap> + <keycap>SHIFT</keycap> + <keycap>F3</keycap> to open that
-dialog and afterwards press <keycap>SHIFT</keycap> + <keycap>ALT</keycap> + <keycap>F1</keycap> to show that
-'XtextEObjectSearchDialog' is used as implementation. Additionally, use
-<keycap>SHIFT</keycap> + <keycap>ALT</keycap> + <keycap>F2</keycap> to spy buttons in the toolbar and
-<keycap>SHIFT</keycap> + <keycap>ALT</keycap> + <keycap>F3</keycap> to spy the extension point name of the
-currently active view or window.</simpara>
-</section>
-</section>
-<section xml:id="sec:Maven-hints">
-<title>Maven</title>
-<section xml:id="how-to-check-for-maven-mojo-updates">
-<title>How to check for Maven MOJO updates</title>
-<simpara><emphasis role="strong">cd</emphasis> to the root directory and call</simpara>
-<programlisting language="bash" linenumbering="unnumbered">mvn versions:display-plugin-updates</programlisting>
-</section>
-</section>
-</appendix>
-<appendix xml:id="_module-loading">
-<title>Module Loading</title>
-<warning>
-<simpara>This chapter is outdated and basically kept for historical reasons.</simpara>
-</warning>
-<section xml:id="sec:Dependency_Management">
-<title>Dependency Management</title>
-<simpara>There exist several types of dependencies between modules, distinguishable by the time when the dependency is relevant. We first define these dependencies lazily to give an impression of the problem, at more rigorously later on.</simpara>
-<simpara>Dependency needed at compile time. These type of dependency is removed by the compiler. These are basically type references used in variable or function declarations.</simpara>
-<simpara>Runtime dependencies are to be handled at runtime in general. We distinguish two special types of runtime dependencies:</simpara>
-<simpara>A loadtime dependency is a special runtime dependency that needs to be resolved before a module is initialized, that is, when all top-level statements of a module, containing class declarations, are executed. This usually is a types super type (e.g., super class), or a call to a function (defined in a different module) in a static initializer or module top level statement.</simpara>
-<simpara>An execution time dependency is a non-initialization runtime dependency. That is, when a method is called (from another module), this is execution time.</simpara>
-<simpara>Of course, before a module can be loaded, it needs to be fetched (i.e., the actual code has to be retrieved by the browser).</simpara>
-<simpara>We can define sets containing modules which a given module depends on. Note that these sets contain each other, as shown in <link linkend="fig:euler_dependencies">Euler Dependencies</link>. However, we define disjoint sets in which a dependency to another type is only contained in one of the sets.</simpara>
-<figure xml:id="fig:euler_dependencies" role="center">
-<title>Euler diagram of dependency sets</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/a10_moduleLoading/images/euler_dependencies.svg"/>
-</imageobject>
-<textobject><phrase>euler dependencies</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Given a code sequence , we define the set of accessed modules in it as .</simpara>
-<literallayout class="monospaced">describes all function calls happening in code block , i.e. . In case calls on functions , we define a function’s body code sequence as .</literallayout>
-<simpara>The complete set of accessed modules for a particular code sequence is then defined as
-]</simpara>
-<simpara>We explicitly allow a function to be excluded from being incorporated in the above algorithm by annotating it.</simpara>
-<simpara>The set of load-time-dependencies for a module with initializer code is then defined as math:[\[\begin{aligned}
-load-time-deps := AccessdModules( SuperClass(M) ) + AccessdModules( IC(M) ) \end{aligned}\]]</simpara>
-</section>
-<section xml:id="ecmascript-modules" role="language-javascript">
-<title>ECMAScript Modules</title>
-<section xml:id="sec:ES5_Modules_Systems">
-<title>ES5 Modules Systems</title>
-<simpara>Before ES6, Javascript had no built in support for modules. To overcome this hurdle, the two widely accepted formats have been :</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>CommonJS</literal> : Primarily aimed at synchronous module loading. The main implementation of this format is seen in <literal>Node.js</literal></simpara>
-<programlisting language="javascript" linenumbering="unnumbered">var value = 100;
-function inc() {
- value++;
-}
-
-module.exports = {
- value : value,
- inc : inc
-}</programlisting>
-<simpara>Import via require.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>AMD</literal> : Primarily aimed at asynchronous module loading in browsers. The main implementation of this format is seen in <literal>RequireJS</literal>.</simpara>
-<screen>define('myModule', ['mod1', 'mod2'], function (mod1, mod2) {
- return {
- myFunc: function(x, y) {
- ..
- }
- };
- };
-});</screen>
-<simpara><literal>passive</literal> format</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:ES6_Modules">
-<title>ES6 Modules</title>
-<simpara>The ES6 spec introduces <link xl:href="http://www.ecma-international.org/ecma-262/6.0/#sec-modules">modules</link>. ES6 modules resemble <literal>CommonJS</literal> syntax with <literal>AMD</literal> like asynchronous loading support.</simpara>
-<simpara>Apart from the syntactic details, the highlights of ES6 modules are :</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>ES6 modules support (multiple) named exports.</simpara>
-<screen>export const VERSION = "1.0.1";
-export function inc(x) {
- return x + 1;
-}</screen>
-</listitem>
-<listitem>
-<simpara>ES6 modules support default exports.</simpara>
-<screen>export default function (x) {
- return x+1;
-}</screen>
-</listitem>
-<listitem>
-<simpara>As specified <link xl:href="http://www.ecma-international.org/ecma-262/6.0/#sec-createimportbinding">here</link>, ES6 modules export live immutable bindings (instead of values).</simpara>
-<note>
-<simpara>This behaviour is different from that of <literal>CommonJS</literal> and <literal>AMD</literal> modules where a snapshot of the value is exported.</simpara>
-</note>
-<simpara>An example demonstrating the behavioural difference :</simpara>
-<screen>//-------------src.js------------
-var value = 100;
-function inc() {
- value++;
-}
-
-module.exports = {
- value : value,
- inc : inc
-}
-//-------------main.js------------
-var src = require("./src"); //import src
-
-console.log(src.value); //prints 100
-src.inc();
-
-console.log(src.value); //prints 100 <--- The value does not update.
-
-src.value = 65;
-console.log(src.value); //prints 65 <--- The imported value is mutable.</screen>
-<simpara>The same example with ES6 modules :</simpara>
-<screen>//-------------src.js------------
-export var value = 100; // <--- ES6 syntax
-export function inc() { // <--- ES6 syntax
- value++;
-}
-
-//-------------main.js------------
-import {value, inc} from "src" // <--- ES6 syntax
-
-console.log(value); //prints 100
-inc();
-
-console.log(value); //prints 101 <--- The value is a live binding.
-
-value = 65; // <--- throws an Error implying the binding is immutable.</screen>
-</listitem>
-<listitem>
-<simpara>ES6 modules impose a static module structure i.e. the imports and exports can be determined at compile time (statically).</simpara>
-</listitem>
-</orderedlist>
-</section>
-</section>
-<section xml:id="sec:ECMAScript_Module_Loaders" role="language-n4js">
-<title>ECMAScript Module Loaders</title>
-<simpara>For resolving module dependencies and loading modules, the JS landscape provides a few different module loaders.</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>RequireJS</literal> is the loader of choice for in browser, <literal>AMD</literal> style modules. We currently transpile our code into an AMD-style format to allow it running in both Browser and Node.js environments.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Node.js</literal> provides a native loader implementation for <literal>CommonJS</literal> style modules.</simpara>
-</listitem>
-<listitem>
-<simpara>For browsers (primarily), tools like <link xl:href="http://webpack.github.io/"><literal>Webpack</literal></link> and <link xl:href="http://browserify.org/"><literal>Browserify</literal></link> exist. These tools analyse the dependency graph of the entire project and then bundle up all the dependencies in a single file. <literal>Browserify</literal> only supports <literal>CommonJS</literal> modules where as <literal>Webpack</literal> works with both <literal>CommonJS</literal> & <literal>AMD</literal> style modules.</simpara>
-</listitem>
-<listitem>
-<simpara>At the time of writing this document (August 2015), there does not exist any native implementation for ES6 modules by any Javascript host environments i.e. ES6 modules are not natively supported by browsers or <literal>Node.js</literal>, as of now.</simpara>
-</listitem>
-</orderedlist>
-<simpara>[fig:moduelLoader] shows an overview.</simpara>
-<figure xml:id="fig:moduleLoader" role="center">
-<title>Module Loader and Transpilers, Overview</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/a10_moduleLoading/images/moduleLoader.svg"/>
-</imageobject>
-<textobject><phrase>moduleLoader</phrase></textobject>
-</mediaobject>
-</figure>
-<section xml:id="sec:ES6_Module_Loaders">
-<title>ES6 Module Loaders</title>
-<simpara>The ES6 spec started out with ES6 Module Loader details as part of the spec. However the Working Group later decided to not proceed with it. The specification for ES6 Module Loader is now a separate specification [<link linkend="WhatWGLoader">WhatWGLoader</link>].</simpara>
-<simpara>The aim of this specification is:</simpara>
-<blockquote>
-<simpara>This specification describes the behavior of loading JavaScript modules from a JavaScript host environment. It also provides APIs for intercepting the module loading process and customizing loading behavior.</simpara>
-</blockquote>
-<simpara>The <link xl:href="https://github.com/whatwg/loader#implementation-status">Implementation status</link> of the spec states :</simpara>
-<blockquote>
-<simpara>It is too early to know about the Loader, first we need ES2015 modules implemented by the various engines.</simpara>
-</blockquote>
-</section>
-<section xml:id="sec:Polyfills_for_ES6_Module_Loaders">
-<title>Polyfills for ES6 Module Loaders</title>
-<simpara>Although there is no native support for ES6 module loading, there are a few attempts to polyfill this gap.</simpara>
-<section xml:id="sec:es6_module_loader">
-<title>es6-module-loader</title>
-<simpara>The <link xl:href="https://github.com/ModuleLoader/es6-module-loader"><literal>es6-module-loader</literal></link> project provides a polyfill for the ES6 Module Loader implementation. It dynamically loads ES6 modules in browsers and <literal>Node.js</literal> with support for loading existing and custom module formats through loader hooks.</simpara>
-</section>
-<section xml:id="sec:SystemJS">
-<title>SystemJS</title>
-<simpara>Building upon <literal>es6-module-loader</literal>, <link xl:href="https://github.com/systemjs/systemjs"><literal>SystemJS</literal></link> supports loading ES6 modules along with <literal>AMD</literal>, <literal>CommonJS</literal> and global scripts in the browser and <literal>Node.js</literal>.</simpara>
-<note>
-<simpara>In order to use ES6 modules (written in ES6 syntax) the code first needs to be transpiled to ES5. For this purpose, <literal>SystemJS</literal> provides an option to use <link xl:href="https://github.com/google/traceur-compiler"><literal>Traceur</literal></link> compiler or <link xl:href="https://babeljs.io/"><literal>Babel</literal></link>.</simpara>
-</note>
-</section>
-<section xml:id="sec:Demo">
-<title>Demo</title>
-<simpara>A demonstration of how to how to use ES6 modules with <literal>Babel</literal> and <literal>SystemJS</literal> in <literal>Node.js</literal> as of today (August 2015).</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Create an ES6 module as shown:</simpara>
-<screen>export var value = 100; // <--- named export of a variable
-export function inc() { // <--- named export of a function
- value++;
-}</screen>
-</listitem>
-<listitem>
-<simpara>Import the bindings from the module as shown:</simpara>
-<screen>import {value, inc} from "src"
-
-var importedValue = value; // <--- using the imported value
-inc(); // <--- using the imported function</screen>
-</listitem>
-<listitem>
-<simpara>Transpile these two files using <literal>Babel</literal> to ES5 with the target module format as <literal>system</literal>, as shown:</simpara>
-<screen>$ babel <inputdir> --out-dir <outputdir> --modules system</screen>
-</listitem>
-<listitem>
-<simpara>The transpiled output should be resemble the following:</simpara>
-<screen>System.register([], function (_export) {
- "use strict";
-
- var value;
-
- _export("inc", inc);
-
- function inc() {
- _export("value", value += 1);
- }
-
- return {
- setters: [],
- execute: function () {
- value = 100;
-
- _export("value", value);
- }
- };
-});</screen>
-<screen>System.register(["src"], function (_export) {
- "use strict";
-
- var value, inc, importedValue;
- return {
- setters: [function (_src) {
- value = _src.value;
- inc = _src.inc;
- }],
- execute: function () {
- importedValue = value;
- inc();
- }
- };
-});</screen>
-</listitem>
-<listitem>
-<simpara>Finally run the above transpiled files, as shown:</simpara>
-<screen>var System = require('systemjs'); // <--- Require SystemJS
-System.transpiler = 'babel'; // <--- Configure SystemJS
-
-System.import('main'); // <--- Import the transpiled "main" module.</screen>
-</listitem>
-</orderedlist>
-</section>
-</section>
-</section>
-<section xml:id="case-study-typescript" role="language-typescript">
-<title>Case Study : TypeScript</title>
-<note>
-<simpara><anchor xml:id="sec:Case_Study___TypeScript" xreflabel="[sec:Case_Study___TypeScript]"/> This section is NOT an exhaustive introduction to Microsoft’s <literal>TypeScript</literal>, but a narrowed down analysis of certain aspects of <literal>TypeScript</literal>.</simpara>
-</note>
-<section xml:id="sec:ES6_Modules_Support">
-<title>ES6 Modules Support</title>
-<simpara><literal>TypeScript</literal> language has recently added support for ES6 modules. From the <link xl:href="https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#es6-modules">wiki</link> :</simpara>
-<blockquote>
-<simpara><literal>TypeScript</literal> 1.5 supports <literal>ECMAScript 6</literal> (ES6) modules. ES6 modules are effectively <literal>TypeScript</literal> external modules with a new syntax: ES6 modules are separately loaded source files that possibly import other modules and provide a number of externally accessible exports. ES6 modules feature several new export and import declarations.</simpara>
-</blockquote>
-</section>
-<section xml:id="sec:TypeScript_and_Module_Loading">
-<title>TypeScript and Module Loading</title>
-<simpara><literal>TypeScript</literal> does not concern itself with providing a module loader. It is the responsibility of the host environment. However <literal>TypeScript</literal>’s compiler provides options to transpile the modules to different formats like <literal>AMD</literal>, <literal>CommonJS</literal>, <literal>ES6</literal> etc. It is the developer’s responsibility to choose an appropriate format and then use the modules with a correct module loader.</simpara>
-<simpara>From the <link xl:href="https://github.com/Microsoft/TypeScript/issues/2242">wiki</link> again :</simpara>
-<blockquote>
-<simpara>TypeScript supports down-level compilation of external modules using the new ES6 syntax. When compiling with <literal>-t ES3</literal> or <literal>-t ES5</literal> a module format must be chosen using <literal>-m CommonJS</literal> or <literal>-m AMD</literal>. When compiling with <literal>-t ES6</literal> the module format is implicitly assumed to be <literal>ECMAScript 6</literal> and the compiler simply emits the original code with type annotations removed. When compiling down-level for <literal>CommonJS</literal> or <literal>AMD</literal>, named exports are emitted as properties on the loader supplied exports instance. This includes default exports which are emitted as assignments to exports.default.</simpara>
-</blockquote>
-<simpara>Consider the following module <literal>src.ts</literal> :</simpara>
-<screen>export var value = 100; //<--- ES6 syntax
-
-export function inc() { //<--- ES6 syntax
- value++;
-}</screen>
-<simpara>Compiling it to <literal>SystemJS</literal> format produces :</simpara>
-<screen>System.register([], function(exports_1) {
- var value;
- function inc() {
- (exports_1("value", ++value) - 1);
- }
- exports_1("inc", inc);
- return {
- setters:[],
- execute: function() {
- exports_1("value", value = 100); //<--- ES6 syntax
- }
- }
-});</screen>
-<simpara>Compiling it to <literal>CommonJS</literal> format produces :</simpara>
-<screen>exports.value = 100; //<--- ES6 syntax
-function inc() {
- exports.value++;
-}
-exports.inc = inc;</screen>
-<simpara>Compiling it to <literal>AMD</literal> format produces :</simpara>
-<screen>define(["require", "exports"], function (require, exports) {
- exports.value = 100; //<--- ES6 syntax
- function inc() {
- exports.value++;
- }
- exports.inc = inc;
-});</screen>
-<simpara>Compiling it to <literal>UMD</literal> format produces :</simpara>
-<screen>(function (deps, factory) {
- if (typeof module === 'object' && typeof module.exports === 'object') {
- var v = factory(require, exports); if (v !== undefined) module.exports = v;
- }
- else if (typeof define === 'function' && define.amd) {
- define(deps, factory);
- }
-})(["require", "exports"], function (require, exports) {
- exports.value = 100; //<--- ES6 syntax
- function inc() {
- exports.value++;
- }
- exports.inc = inc;
-});</screen>
-<simpara>NOTE :</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Visual Studio 2015 does not <link xl:href="http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/7017377-support-for-es6-modules">support</link> ES6 modules at this time.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>SystemJS</literal> supports <literal>TypeScript</literal> as a compiler. This implies <literal>TypeScript</literal> modules can be transpiled to be used with <literal>SystemJS</literal> as the module loader.</simpara>
-</listitem>
-</orderedlist>
-</section>
-</section>
-<section xml:id="sec:Cyclic_Dependencies" role="language-js">
-<title>Cyclic Dependencies</title>
-<simpara>To better analyse and evaluate <literal>SystemJS</literal> module loader and different module formats, let’s look at a cyclic dependency example from a (extremely simplified) stdlib task <literal>FixedPoint6</literal>. The outline for the example is :</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Prepare 2 ES6 modules with a circular dependency.</simpara>
-</listitem>
-<listitem>
-<simpara>Then transpile these modules to different module formats (e.g. <literal>AMD</literal>, & <literal>SystemJS</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>With <literal>SystemJS</literal> as the module loader, execute the test for every transpiled module format.</simpara>
-</listitem>
-</orderedlist>
-<section xml:id="sec:Setup">
-<title>Setup</title>
-<simpara>Consider the following ES6 listings:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>RoundingMode</simpara>
-<screen>export default {
- FLOOR : "FLOOR",
- CEILING : "CEILING"
-}</screen>
-</listitem>
-<listitem>
-<simpara>MathContext</simpara>
-<screen>import { default as FixedPoint6 } from "FixedPoint6";
-import { default as RoundingMode } from "RoundingMode";
-
-let MathContext = class {
- constructor(mode) {
- this.mode = mode;
- }
-
- divide(fp1, fp2) {
- var quotient = FixedPoint6.getQuotient(fp1, fp2);
-
- if(this.mode === RoundingMode.CEILING) {
- return new FixedPoint6(Math.ceil(quotient));
- } else if(this.mode === RoundingMode.FLOOR) {
- return new FixedPoint6(Math.floor(quotient));
- } else {
- throw new Error("Incorrect RoundingMode");
- }
- }
-}
-
-MathContext.FLOOR = new MathContext(RoundingMode.FLOOR);
-MathContext.CEILING = new MathContext(RoundingMode.CEILING);
-
-export default MathContext;</screen>
-</listitem>
-<listitem>
-<simpara>FixedPoint6</simpara>
-<screen>import { default as MathContext } from "MathContext";
-
-export default class FixedPoint6 {
- constructor(number) {
- this.value = number;
- }
-
- static getQuotient(fp1, fp2) {
- return fp1.value/fp2.value;
- }
-
- divide(fp) {
- return FixedPoint6.defaultContext.divide(this, fp);
- }
-}
-
-FixedPoint6.defaultContext = MathContext.FLOOR;</screen>
-</listitem>
-<listitem>
-<simpara>Test</simpara>
-<screen>import { default as FixedPoint6 } from "FixedPoint6";
-import { default as MathContext } from "MathContext";
-import { default as RoundingMode } from 'RoundingMode';
-
-var fp1 = new FixedPoint6(20.5);
-var fp2 = new FixedPoint6(10);
-
-var fp3 = fp1.divide(fp2);
-console.log(fp1, fp2, fp3);</screen>
-</listitem>
-<listitem>
-<simpara>Runner : This is the runner file to execute the test (after transpilation).</simpara>
-<screen>var System = require('systemjs');
-System.transpiler = 'babel';
-
-System.config({
- baseURL: './build',
- "paths": {
- "*": "*.js"
- }
-});
-
-System.import('test').catch(function(e) {
- console.log(e);
-})</screen>
-</listitem>
-</orderedlist>
-<simpara>Clearly <literal>MathContext</literal> & <literal>FixedPoint6</literal> have a circular dependency upon each other.</simpara>
-</section>
-<section xml:id="sec:Transpile_and_Execute" role="language-js">
-<title>Transpile and Execute</title>
-<simpara>Transpile the above setup to different formats and execute the code using <literal>SystemJS</literal> module loader :</simpara>
-<section xml:id="sec:Module_Format___AMD">
-<title>Module Format = AMD</title>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Compile the previous set up using <literal>babel</literal> as the transpiler with <literal>AMD</literal> modules :</simpara>
-<screen>babel src -w --out-dir build --modules amd</screen>
-</listitem>
-<listitem>
-<simpara>Run the transpiled <literal>test.js</literal> with :</simpara>
-<screen>node runner.js</screen>
-</listitem>
-<listitem>
-<simpara>The execution would fail with an error like the following :</simpara>
-<screen>Error: _FixedPoint62.default.getQuotient is not a function</screen>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Module_Format___CommonJS">
-<title>Module Format = CommonJS</title>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Compile the previous set up using <literal>babel</literal> as the transpiler with <literal>CommonJS</literal> modules :</simpara>
-<screen>babel src -w --out-dir build --modules common</screen>
-</listitem>
-<listitem>
-<simpara>Run the transpiled <literal>test.js</literal> with :</simpara>
-<screen>node runner.js</screen>
-</listitem>
-<listitem>
-<simpara>The execution is successful and logs the following results :</simpara>
-<screen>{ value: 20.5 } { value: 10 } { value: 2 }</screen>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Module_Format___SystemJS">
-<title>Module Format = SystemJS</title>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Compile the previous set up using <literal>babel</literal> as the transpiler with <literal>SystemJS</literal> modules :</simpara>
-<screen>babel src -w --out-dir build --modules system</screen>
-</listitem>
-<listitem>
-<simpara>Run the transpiled <literal>test.js</literal> with :</simpara>
-<screen>node runner.js</screen>
-</listitem>
-<listitem>
-<simpara>The execution is successful and logs the following results :</simpara>
-<screen>{ value: 20.5 } { value: 10 } { value: 2 }</screen>
-</listitem>
-</orderedlist>
-</section>
-</section>
-<section xml:id="sec:Conclusion">
-<title>Conclusion</title>
-<simpara>As observed, the test is executed successfully with <literal>CommonJS</literal> & <literal>SystemJS</literal> module formats. It however fails with <literal>AMD</literal> format (due to the circular dependency).</simpara>
-</section>
-</section>
-<section xml:id="system.register-as-transpilation-target" role="language-n4js">
-<title>System.register as transpilation target</title>
-<simpara>In order to integrate <literal>SystemJS</literal> as the module loader, the recommended module format is <literal>System.register</literal>. This section serves as a guide (& implementation hint) to transpile N4JS modules with <literal>System.register</literal> as the module format.</simpara>
-<section xml:id="sec:Introduction">
-<title>Introduction</title>
-<simpara>This format is best explained from its <link xl:href="https://github.com/ModuleLoader/es6-module-loader/blob/master/docs/system-register.md">documentation</link> :</simpara>
-<blockquote>
-<simpara>System.register can be considered as a new module format designed to support the exact semantics of ES6 modules within ES5. It is a format that was developed out of collaboration and is supported as a module output in Traceur (as instantiate), Babel and TypeScript (as system). All dynamic binding and circular reference behaviors supported by ES6 modules are supported by this format. In this way it acts as a safe and comprehensive target format for the polyfill path into ES6 modules.</simpara>
-<simpara>To run the format, a suitable loader implementation needs to be used that understands how to execute it. Currently these include SystemJS, SystemJS Self-Executing Bundles and ES6 Micro Loader. The ES6 Module Loader polyfill also uses this format internally when transpiling and executing ES6.</simpara>
-</blockquote>
-<simpara>The <literal>System.register</literal> format is not very well documented. However, this format is supported by all major transpilers out there i.e. <literal>BabelJS</literal>, <literal>Traceur</literal> & <literal>TypeScript</literal> transpilers. In fact, the primary resource of this documentation has been the outputs generated by these transpilers.</simpara>
-<section xml:id="sec:External_Transpilers">
-<title>External Transpilers</title>
-<simpara>In order to follow along, it will be best to try out different ES6 syntax being transpiled to <literal>System.register</literal> format by these transpilers.</simpara>
-<simpara>The following instructions will be useful :</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Transpile with Traceur</simpara>
-<programlisting language="bash" linenumbering="unnumbered">traceur --dir <SOURCE_DIR> <OUTPUT_DIR> --experimental --modules=instantiate</programlisting>
-</listitem>
-<listitem>
-<simpara>Transpile with Babel</simpara>
-<programlisting language="bash" linenumbering="unnumbered">babel <SOURCE_DIR> --out-dir <OUTPUT_DIR> --modules system</programlisting>
-</listitem>
-<listitem>
-<simpara>Transpile with TypeScript</simpara>
-<simpara>Create a file by the name of <literal>tsconfig.json</literal> in the project folder, with the following contents :</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- "compilerOptions": {
- "module": "system",
- "target": "ES5",
- "outDir": <OUTPUT_DIR>,
- "rootDir": <SOURCE_DIR>
- }
-}</programlisting>
-<simpara>Then transpile with :</simpara>
-<programlisting language="javascript" linenumbering="unnumbered">tsc</programlisting>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Example_of_a_System_register_module">
-<title>Example of a System.register module</title>
-<simpara>For the following ES6 code :</simpara>
-<programlisting language="javascript" linenumbering="unnumbered">import { p as q } from './dep';
-
-var s = 'local';
-
-export function func() {
- return q;
-}
-
-export class C {}</programlisting>
-<simpara>The <literal>Babel</literal> transpiler generates the following code (w/ <literal>System.register</literal> format):</simpara>
-<programlisting language="javascript" linenumbering="unnumbered">System.register(['./dep'], function (_export) {
- 'use strict';
-
- var q, s, C;
-
- _export('func', func);
-
- function _classCallCheck(instance, Constructor) { .. }
-
- function func() {
- return q;
- }
-
- return {
- setters: [function (_dep) {
- q = _dep.p;
- }],
- execute: function () {
- s = 'local';
-
- C = function C() {
- _classCallCheck(this, C);
- };
-
- _export('C', C);
- }
- };
-});</programlisting>
-</section>
-</section>
-<section xml:id="sec:Structure_of_a_System_register_module">
-<title>Structure of a System.register module</title>
-<simpara>Broadly speaking, a <literal>System.register</literal> module has the following structure :</simpara>
-<programlisting language="javascript" linenumbering="unnumbered">System.register(<<DEPENDENCIES ARRAY>>, function(<<exportFn>>) {
- <<DECLARATION SCOPE>>
-
- return {
- setters: <<SETTERS ARRAY>>,
- execute: function() {
- <<EXECUTABLES>>
- }
- };
-});</programlisting>
-<simpara>Highlights :</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>System.register(…​)</literal> is called with 2 arguments :</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal><<DEPENDENCIES ARRAY>></literal> : an array of dependencies (similar to <literal>AMD</literal>) extracted from the <literal>ES6 import</literal> statements.</simpara>
-</listitem>
-<listitem>
-<simpara>a function (<literal>FN</literal>) :</simpara>
-<itemizedlist>
-<listitem>
-<simpara>accepts a parameter called <literal><<exportFn>></literal>. This <literal><<exportFn>></literal> (provided by <literal>SystemJS</literal>) keeps a track of all the exports of this module & will inform all the importing modules of any changes.</simpara>
-</listitem>
-<listitem>
-<simpara>contains a <literal><<DECLARATION SCOPE>></literal> where all the functions and variables (from the source code) get hoisted to.</simpara>
-</listitem>
-<listitem>
-<simpara>returns an object with 2 properties :</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>setters</literal> : The <literal><<SETTERS ARRAY>></literal> is simply an array of functions. Each of these functions represents the imported-bindings from the <literal><<DEPENDENCIES ARRAY>></literal>. The <literal><<SETTERS ARRAY>></literal> and <literal><<DEPENDENCIES ARRAY>></literal> follow the same order.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>execute</literal> : <literal><<EXECUTABLES>></literal> is the rest of the body of the source code.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_transpilation-hints">
-<title>Transpilation Hints</title>
-<simpara>By observing the existing transpilers’ output, this sub-section provides insights into the process of transpiling to this format :</simpara>
-<section xml:id="sec:Handling_Imports">
-<title>Handling Imports</title>
-<simpara>The following are ES6 code snippets with some <literal>import</literal> statements :</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Simple Import Statement</simpara>
-<programlisting language="javascript" linenumbering="unnumbered">import {b1} from 'B';</programlisting>
-<simpara>A valid <literal>System.register</literal> output for this snippet would look like :</simpara>
-<screen>System.register(['B'], function (<<exportFn>>) { //(1.)
-
- var b1; //(2.)
-
- return {
-
- //(3.)
- setters: [function (_B) {
- b1 = _B.b1; //(4.)
- }],
-
- execute: function () {}
- };
-});</screen>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>highlights</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The <literal><<DEPENDENCIES ARRAY>></literal> is just <literal>[’B’]</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal><<DECLARATION SCOPE>></literal> simply declares the imported binding <literal>v1</literal> as a variable.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal><<SETTERS ARRAY>></literal> has 1 function. This function corresponds to the single dependency (<literal>’B’</literal>) from (1.)</simpara>
-</listitem>
-<listitem>
-<simpara>The setter function accepts one argument (the exported object from <literal>’B’</literal> as <literal>_B</literal> . It then sets the local binding (i.e. local variable <literal>v1</literal>) to <literal>_B.b1</literal>.</simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Takeaway</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>An <literal>import</literal> statement is broken down into <literal><<DEPENDENCIES ARRAY>></literal> & <literal><<SETTERS ARRAY>></literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Whenever the value of <literal>b1</literal> inside <literal>B</literal> is changed, <literal>SystemJS</literal> will execute the corresponding <literal>setter function</literal> in this module i.e. the 1st function in this case.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-<listitem>
-<simpara>Multiple Import Statements</simpara>
-<screen>import { a1 as a0 } from 'A';
-import {b1} from 'B';
-import { c1 as c0 } from 'C';
-import {b2, b3} from 'B';
-import {default} from 'C';
-import {a2} from 'A';</screen>
-<simpara>A valid <literal>System.register</literal> output for this snippet would look like :</simpara>
-<screen>System.register(['A', 'B', 'C'], function (<<exportFn>>) { //(1.)
-
- var a0, a2, b1, b2, b3, c0, default; //(2.)
-
- return {
-
- //(3.)
- setters: [function (_A) {
- a0 = _A.a1; //(4.1.)
- a2 = _A.a2; //(4.2.)
- }, function (_B) {
- b1 = _B.b1;
- b2 = _B.b2;
- b3 = _B.b3;
- }, function (_C) {
- c0 = _C.c1;
- default = _C['default'];
- }],
-
-
- execute: function () {}
- };
-});</screen>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>highlights</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The <literal><<DEPENDENCIES ARRAY>></literal> is now a unique array <literal>[’A’, ’B’, ’C’]</literal>. Note that there are no duplicates.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal><<DECLARATION SCOPE>></literal> simply declares all the imported bindings as variables.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal><<SETTERS ARRAY>></literal> now has 3 functions. These 3 functions match the ordering of the <literal><<DEPENDENCIES ARRAY>></literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The setter function accepts one argument (the exported object from the dependency) It then sets the local bindings (i.e. local variables) from the exported value of the dependency.</simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Takeaway</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>Whenever an exported value from <literal>A</literal> is changed, <literal>SystemJS</literal> will execute the first <literal>setter function</literal> in this module.</simpara>
-</listitem>
-<listitem>
-<simpara>Whenever an exported value from <literal>B</literal> is changed, <literal>SystemJS</literal> will execute the second <literal>setter function</literal> in this module.</simpara>
-</listitem>
-<listitem>
-<simpara>Whenever an exported value from <literal>C</literal> is changed, <literal>SystemJS</literal> will execute the third <literal>setter function</literal> in this module.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:__exportFn__">
-<title><<exportFn>></title>
-<simpara>Before moving on to handling exports, let’s focus on the SystemJS provided <literal><<exportFn>></literal>.</simpara>
-<simpara>This function looks similar to the following :</simpara>
-<screen>function (name, value) { //(1.)
- module.locked = true;
-
- if (typeof name == 'object') {
- for (var p in name)
- exports[p] = name[p]; //(2.1.)
- }
- else {
- exports[name] = value; //(2.2.)
- }
-
- for (var i = 0, l = module.importers.length; i < l; i++) {
- var importerModule = module.importers[i];
- if (!importerModule.locked) {
- var importerIndex = indexOf.call(importerModule.dependencies, module);
- importerModule.setters[importerIndex](exports); //(3.)
- }
- }
-
- module.locked = false;
- return value; //(4.)
-}</screen>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>highlights</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The <literal><<exportFn>></literal> takes 2 arguments : <literal>name</literal> & <literal>value</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>It maintains an <literal>exports</literal> object with <literal>name</literal> & <literal>value</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>For every module which imports the current module, it executes the corresponding <literal>setter function</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>It returns the <literal>value</literal>.</simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Takeaway</simpara>
-</entry>
-<entry>
-<simpara>This <literal><<exportFn>></literal> is responsible for pushing the changes from a module to every importing module thereby implementing the live binding.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Handling_Exports">
-<title>Handling Exports</title>
-<simpara>Now let’s focus on handling <literal>export</literal> statements.</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Simple Exports Statement</simpara>
-<screen>export var v =1;
-export function f(){}</screen>
-<simpara>A valid <literal>System.register</literal> output for this snippet would look like :</simpara>
-<screen>System.register([], function (_export) { //(1.)
-
- //(2.)
- var v;
- function f() {}
-
- _export("f", f); //(4.1)
-
- return {
- setters: [],
-
- //(3.)
- execute: function () {
- v = 1; //(3.1.)
-
- _export("v", v); //(4.2.)
- }
- };
-});</screen>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>highlights</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The <literal><<exportFn>></literal> is named to as <literal>_export</literal>. (This is an implementation decision by Babel.) The name should be unique to not conflict with any user-defined variable/function names.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal><<DECLARATION SCOPE>></literal> hoists the exported variable <literal>v</literal> and the function <literal>f</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal><<EXECUTABLES>></literal> zone now contains the executable code from the source module.</simpara>
-</listitem>
-<listitem>
-<simpara>Initialise the variable <literal>v1</literal> with the value extracted from the source. This essentially is the executable part of the module.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal>export</literal> function expression results in a call to the <literal>_exports</literal> function as: <literal>_export(f, f)</literal></simpara>
-</listitem>
-<listitem>
-<simpara>The <literal>export</literal> statement results in a call to the <literal>_export</literal> function as: <literal>_export(v, v)</literal></simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Takeaway</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>The module’s exports statements are separated from the hoistable and executable statements.</simpara>
-</listitem>
-<listitem>
-<simpara>All the exported bindings are tracked by wrapping them inside the <literal><<exportFn>></literal>.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-<listitem>
-<simpara>Tracking Exported Bindings</simpara>
-<simpara>To maintain live bindings, <literal>SystemJS</literal> needs to track any changes to exported bindings in order to call the <literal>setter</literal> functions of importing modules. Let’s look at an example for that :</simpara>
-<screen>export var v1 = 1;
-export var v2 = 2;
-export var v3 = 3;
-export function f() {}
-
-v1++; //(1.)
-++v2; //(2.)
-v3 += 5; //(3.)
-f = null; //(4.)</screen>
-<simpara><literal>Babel</literal> output for this snippet looks like :</simpara>
-<screen>System.register([], function (_export) {
-
- var v1, v2, v3;
-
- _export("f", f);
-
- function f() {}
-
- return {
- setters: [],
-
- execute: function () {
- v1 = 1;
-
- _export("v1", v1);
-
- v2 = 2;
-
- _export("v2", v2);
-
- v3 = 3;
-
- _export("v3", v3);
-
- _export("v1", v1 += 1); //(1.)
- _export("v2", v2 += 1); //(2.)
- _export("v3", v3 += 5); //(3.)
- _export("f", f = null); //(4.)
- }
- };
-});</screen>
-<simpara><literal>Traceur</literal> output for this snippet looks like :</simpara>
-<screen>System.register([], function($__export) {
-
- var v1, v2, v3;
- function f() {}
-
- $__export("f", f);
-
- return {
- setters: [],
-
- execute: function() {
- v1 = 1;
- $__export("v1", v1);
- v2 = 2;
- $__export("v2", v2);
- v3 = 3;
- $__export("v3", v3);
-
- ($__export("v1", v1 + 1), v1++); //(1.)
- $__export("v2", ++v2); //(2.)
- $__export("v3", v3 += 5); //(3.)
- $__export("f", f = null); //(4.)
- }
- };
-});</screen>
-<simpara><literal>TypeScript</literal> output for this snippet looks like :</simpara>
-<screen>System.register([], function(exports_1) {
- var v1, v2, v3;
- function f() { }
-
- exports_1("f", f);
-
- return {
- setters:[],
-
- execute: function() {
- exports_1("v1", v1 = 1);
- exports_1("v2", v2 = 2);
- exports_1("v3", v3 = 3);
-
- (exports_1("v1", ++v1) - 1); //(1.)
- exports_1("v2", ++v2); //(2.)
- exports_1("v3", v3 += 5); //(3.)
- f = null; //(4.)
- }
- }
-});</screen>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>highlights</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>The re-assignment of <literal>v1, v2, v3 and f</literal> is wrapped inside a call to the <literal><<exportFn>></literal> with the updated value.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Takeaway</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>While transpiling we need to detect if any exported binding is reassigned. In that case invoke the <literal><<exportFn>></literal> immediately with the new value.</simpara>
-</listitem>
-<listitem>
-<simpara>Different transpilers perform different optimization tricks, which may be worth looking at.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-<listitem>
-<simpara>Exporting a Class extending an imported Class.</simpara>
-<simpara>Let’s look at the following class declaration :</simpara>
-<screen>import {A} from "A"; //<-- import class A
-
-export class C extends A {}</screen>
-<simpara><literal>Babel</literal> output for this snippet looks like :</simpara>
-<screen>System.register(["A"], function (_export) {
-
- var A, C;
-
- var _get = function get(_x, _x2, _x3) { ... };
-
- function _classCallCheck(instance, Constructor) { ... }
-
- function _inherits(subClass, superClass) { ... }
-
- return {
- setters: [function (_A2) {
- A = _A2.A;
- }],
-
- execute: function () { //(1.)
- C = (function (_A) {
- _inherits(C, _A);
-
- function C() {
- _classCallCheck(this, C);
-
- _get(Object.getPrototypeOf(C.prototype), "constructor", this).apply(this, arguments);
- }
-
- return C;
- })(A);
-
- _export("C", C);
- }
- };
-});</screen>
-<simpara><literal>Traceur</literal> output for this snippet looks like :</simpara>
-<screen>System.register(["A"], function($__export) {
- var A, C;
-
- return {
- setters: [function($__m) {
- A = $__m.A;
- }],
-
- execute: function() { //(1.)
- C = $traceurRuntime.initTailRecursiveFunction(function($__super) {
- return $traceurRuntime.call(function($__super) {
- function C() {
- $traceurRuntime.superConstructor(C).apply(this, arguments);
- }
- return $traceurRuntime.continuation($traceurRuntime.createClass, $traceurRuntime, [C, {}, {}, $__super]);
- }, this, arguments);
- })(A);
- $__export("C", C);
- }
- };
-});</screen>
-<simpara><literal>TypeScript</literal> output for this snippet looks like :</simpara>
-<screen>System.register(["A"], function(exports_1) {
- var __extends = function(){ ... }
- var A_1;
- var C;
-
- return {
- setters:[
- function (A_1_1) {
- A_1 = A_1_1;
- }],
-
- execute: function() { //(1.)
- C = (function (_super) {
- __extends(C, _super);
- function C() {
- _super.apply(this, arguments);
- }
- return C;
- })(A_1.A);
- exports_1("C", C);
- }
- }
-});</screen>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>highlights</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Notice how the construction of class <literal>C</literal> has now been deferred to the <literal><<EXECUTABLES>></literal> zone. It is because <literal>C</literal> depends on <literal>A</literal> being imported first.</simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Takeaway</simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>The <literal><<DECLARATION SCOPE>></literal> is for hoisting only independent entities i.e. the ones that do not depend upon any imports. Everything else is moved to the <literal><<EXECUTABLES>></literal> region.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</listitem>
-</orderedlist>
-</section>
-</section>
-<section xml:id="sec:Examples_w__Circular_Dependencies">
-<title>Examples w/ Circular Dependencies</title>
-<simpara>This section focuses on circular dependencies. The goal is to see how the transpiled output looks like and if the execution is possible.</simpara>
-<informalexample>
-<simpara>Source files:</simpara>
-<screen>import B from "B";
-
-export default class A {}
-A.b = new B(); //<---</screen>
-<screen>import A from "A";
-
-export default class B {}
-B.a = new A(); //<---</screen>
-<simpara>Transpiled Outputs (w/ Babel):<?asciidoc-br?></simpara>
-<screen>System.register(["B"], function (_export) {
- "use strict";
-
- var B, A;
-
- function _classCallCheck(instance, Constructor) {...}
-
- return {
- setters: [function (_B) {
- B = _B["default"];
- }],
- execute: function () {
- A = function A() {
- _classCallCheck(this, A);
- };
-
- _export("default", A);
-
- A.b = new B();
- }
- };
-});</screen>
-<screen>System.register(["A"], function (_export) {
- "use strict";
-
- var A, B;
-
- function _classCallCheck(instance, Constructor) {...}
-
- return {
- setters: [function (_A) {
- A = _A["default"];
- }],
- execute: function () {
- B = function B() {
- _classCallCheck(this, B);
- };
-
- _export("default", B);
-
- B.a = new A();
- }
- };
-});</screen>
-<simpara>Execution Result<?asciidoc-br?></simpara>
-<screen>var System = require('systemjs');
-
-System.import('A', 'B').then(function(resp) {
- var a = new A();
- var b = new B();
-}).catch(function(e) {
- console.log(e);
-});</screen>
-<screen>Babel : [Error: undefined is not a function]</screen>
-</informalexample>
-<informalexample>
-<simpara>Source files:</simpara>
-<screen>import {B} from "B";
-
-export class A extends B{}</screen>
-<screen>import {A} from "A";
-
-export class B{}
-class C extends A{}</screen>
-<simpara>Transpiled Outputs (w/ Babel) :<?asciidoc-br?></simpara>
-<screen>System.register(["B"], function (_export) {
- "use strict";
-
- var B, A;
-
- var _get = function get(_x, _x2, _x3) { ... };
-
- function _classCallCheck(instance, Constructor) { ... }
-
- function _inherits(subClass, superClass) {...}
-
- return {
- setters: [function (_B2) {
- B = _B2.B;
- }],
- execute: function () {
- A = (function (_B) {
- _inherits(A, _B);
-
- function A() {
- _classCallCheck(this, A);
-
- _get(Object.getPrototypeOf(A.prototype), "constructor", this).apply(this, arguments);
- }
-
- return A;
- })(B);
-
- _export("A", A);
- }
- };
-});</screen>
-<screen>System.register(["A"], function (_export) {
- "use strict";
-
- var A, B, C;
-
- var _get = function get(_x, _x2, _x3) { ... };
-
- function _inherits(subClass, superClass) { ... }
-
- function _classCallCheck(instance, Constructor) { ... }
-
- return {
- setters: [function (_A2) {
- A = _A2.A;
- }],
- execute: function () {
- B = function B() {
- _classCallCheck(this, B);
- };
-
- _export("B", B);
-
- C = (function (_A) {
- _inherits(C, _A);
-
- function C() {
- _classCallCheck(this, C);
-
- _get(Object.getPrototypeOf(C.prototype), "constructor", this).apply(this, arguments);
- }
-
- return C;
- })(A);
- }
- };
-});</screen>
-<simpara>Execution Result<?asciidoc-br?></simpara>
-<screen>var System = require('systemjs');
-
-System.import('A','B').then(function(resp) {
- var a = new A();
-}).catch(function(e) {
- console.log(e);
-});</screen>
-<screen>TypeScript : [Error: Cannot read property 'prototype' of undefined]
-Babel : [Error: Super expression must either be null or a function, not undefined]</screen>
-</informalexample>
-<informalexample>
-<simpara>Source files:</simpara>
-<screen>import B from "B";
-
-class A extends B {}
-export default class X {}</screen>
-<screen>import X from "A";
-
-export default class B {}
-class Y extends X {}</screen>
-<simpara>Transpiled Outputs (w/ Babel):<?asciidoc-br?></simpara>
-<screen>System.register(["B"], function (_export) {
- "use strict";
-
- var B, A, X;
-
- var _get = function get(_x, _x2, _x3) { ... };
-
- function _classCallCheck(instance, Constructor) { ... }
-
- function _inherits(subClass, superClass) { ... }
-
- return {
- setters: [function (_B2) {
- B = _B2["default"];
- }],
- execute: function () {
- A = (function (_B) {
- _inherits(A, _B);
-
- function A() {
- _classCallCheck(this, A);
-
- _get(Object.getPrototypeOf(A.prototype), "constructor", this).apply(this, arguments);
- }
-
- return A;
- })(B);
-
- X = function X() {
- _classCallCheck(this, X);
- };
-
- _export("default", X);
- }
- };
-});</screen>
-<screen>System.register(["A"], function (_export) {
- "use strict";
-
- var X, B, Y;
-
- var _get = function get(_x, _x2, _x3) { ... };
-
- function _inherits(subClass, superClass) { ... }
-
- function _classCallCheck(instance, Constructor) { ... }
-
- return {
- setters: [function (_A) {
- X = _A["default"];
- }],
- execute: function () {
- B = function B() {
- _classCallCheck(this, B);
- };
-
- _export("default", B);
-
- Y = (function (_X) {
- _inherits(Y, _X);
-
- function Y() {
- _classCallCheck(this, Y);
-
- _get(Object.getPrototypeOf(Y.prototype), "constructor", this).apply(this, arguments);
- }
-
- return Y;
- })(X);
- }
- };
-});</screen>
-<simpara>Execution Result<?asciidoc-br?></simpara>
-<screen>var System = require('systemjs');
-
-System.import('A').then(function(resp) {
- var a = new A();
-}).catch(function(e) {
- console.log(e);
-});</screen>
-<screen>TypeScript : [Error: Cannot read property 'prototype' of undefined]
-Babel : [[Error: Super expression must either be null or a function, not undefined]]</screen>
-</informalexample>
-</section>
-<section xml:id="sec:N4JS_Examples_w__Circular_Dependencies">
-<title>N4JS Examples w/ Circular Dependencies</title>
-<simpara>In order to improve our precision in conversing and discussing about different kinds of circular dependencies, this section provides the most basic examples of different kinds.</simpara>
-<section xml:id="sec:Unresolved_Cyclic_Dependencies">
-<title>Unresolved Cyclic Dependencies</title>
-<simpara>Below examples demonstrate cases when cyclic dependency cannot be resolved at all and will cause runtime errors.</simpara>
-<example>
-<title>Circular dependency resolution 1</title>
-<screen>import b from "B"
-
-export public var number a = 1;
-export public var number a2 = b + 1;</screen>
-<screen>import a from "A"
-
-export public var number b = a + 1;</screen>
-<screen>import a2 from "A"
-console.log(a2); //<-- should be 3. not NaN.</screen>
-</example>
-<example>
-<title>Circular dependency resolution 2</title>
-<screen>import B from "B"
-
-export public class A {
- static a = B.b + 1;
-}</screen>
-<screen>import A from "A"
-export public class B {
- static b = 1;
-}
-export public class B2 {
- static b2 = A.a;
-}</screen>
-<screen>import B2 from "B"
-console.log(B2.b2); //should log 2</screen>
-</example>
-<example>
-<title>Circular dependency resolution 3</title>
-<screen>import B from "B"
-export public class A {
- B b = new B();
-}</screen>
-<screen>import A from "A"
-export public class B {
- A a = new A();
-}</screen>
-<screen>import A from "A"
-new A(); // should not cause a runtime error.</screen>
-</example>
-</section>
-<section xml:id="sec:Variables___Functions">
-<title>Examples with Variables & Functions</title>
-<example>
-<title>Circular dependency resolution 4</title>
-<screen>import b_fun from "B"
-
-export public var a2 = b_fun();
-export public var a = 1;</screen>
-<screen>import a from "A"
-
-export public function b_fun() {
- return a + 1;
-}</screen>
-<screen>import a2 from "A"
-console.log(a2); //<-- should be 2. not NaN.</screen>
-</example>
-</section>
-<section xml:id="sec:Classes">
-<title>Examples with Classes</title>
-<example>
-<title>Circular dependency resolution 5</title>
-<screen>import B from "B"
-export public class A {
- static a1 = 1;
- static a2 = B.b1;
-}</screen>
-<screen>import A from "A"
-export public class B {
- static b1 = A.a1;
-}</screen>
-<screen>import A from "A"
-console.log(A.a1); //should log 1. not an error.</screen>
-</example>
-<example>
-<title>Circular dependency resolution 6</title>
-<screen>import B from "B"
-export public class A {
- static a1 = 1;
- static a2 = B.b1;
-}</screen>
-<screen>import A from "A"
-export public class B {
- static b1 = -1;
- static b2 = A.a1;
-}</screen>
-<screen>import A from "A"
-console.log(A.a1);//should log 1. not an error.</screen>
-</example>
-<example>
-<title>Circular dependency resolution 7</title>
-<screen>import B from "B"
-export public class A {
- static a = new B();
-}</screen>
-<screen>import A from "A"
-export public class B {
- static b = new A();
-}</screen>
-<screen>import A from "A"
-new A(); //should succeed.</screen>
-</example>
-</section>
-<section xml:id="sec:Examples_with_SubClassing">
-<title>Examples with SubClassing</title>
-<example>
-<title>Circular dependency resolution 8</title>
-<screen>import B from "B"
-export public class A {}
-export public class C extends B {}</screen>
-<screen>import A from "A"
-export public class B extends A{}</screen>
-<screen>import C from "A"
-new C();//should succeed.</screen>
-</example>
-<example>
-<title>Circular dependency resolution 9</title>
-<screen>import B from "B"
-export public class A {}
-export public class C {
- c = new B();
-}</screen>
-<screen>import A from "A"
-export public class B extends A{}</screen>
-<screen>import C from "A"
-new C(); //should succeed.</screen>
-</example>
-</section>
-<section xml:id="sec:Miscellaneous">
-<title>Miscellaneous</title>
-<example>
-<title>Circular dependency resolution 10</title>
-<screen>import B from "B"
-export public class A {}
-new B();</screen>
-<screen>import A from "A"
-export public class B {}
-new A();</screen>
-<screen>import A from "A"
-new A() //should succeed.</screen>
-</example>
-<example>
-<title>Circular dependency resolution 11</title>
-<screen>import B from "B"
-export public class A {}
-B.b1;</screen>
-<screen>import A from "A"
-export public class B {
- static b1;
-}
-new A();</screen>
-<screen>import A from "A"
-new A() //should succeed.</screen>
-</example>
-</section>
-</section>
-<section xml:id="_resources">
-<title>Resources</title>
-<simpara><link xl:href="https://github.com/ModuleLoader/es6-module-loader/blob/master/docs/system-register.md">Wiki</link></simpara>
-</section>
-</section>
-<section xml:id="sec:CommonJS_as_transpilation_target" role="language-js">
-<title>CommonJS as transpilation target</title>
-<simpara>To provide better compatibility with <literal>npm</literal> eco-system, we want to transpile <literal>N4JS</literal> code to <literal>CommonJS</literal> module format.</simpara>
-<section xml:id="_introduction-2">
-<title>Introduction</title>
-<simpara>A sample <literal>CommonJS</literal> module :</simpara>
-<screen>var lib1 = require("/lib1"); //<-- require
-var lib2 = require("/lib2"); //<-- require
-
-function fn() {
- //...something using 'lib1' & 'lib2'
-}
-
-exports.usefulFn = fn; //<--exports
-exports.uselessValue = 42; //<--exports</screen>
-<simpara>The <link xl:href="http://www.commonjs.org/specs/modules/1.0/">CommonJS spec</link> describes the salient features of module format as (quoted verbatim) :</simpara>
-<blockquote>
-<simpara>Module Context</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>In a module, there is a free variable "require", that is a
-function.</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>The "require" function accepts a module identifier.</simpara>
-</listitem>
-<listitem>
-<simpara>"require" returns the exported API of the foreign module.</simpara>
-</listitem>
-<listitem>
-<simpara>If there is a dependency cycle, the foreign module may
-not have finished executing at the time it is required by one
-of its transitive dependencies; in this case, the object
-returned by "require" must contain at least the exports
-that the foreign module has prepared before the call to
-require that led to the current module’s execution.</simpara>
-</listitem>
-<listitem>
-<simpara>If the requested module cannot be returned, "require"
-must throw an error.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>In a module, there is a free variable called "exports",
-that is an object that the module may add its API to as it
-executes.</simpara>
-</listitem>
-<listitem>
-<simpara>modules must use the "exports" object as the only means
-of exporting.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Module Identifiers</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A module identifier is a String of "terms" delimited by forward
-slashes.</simpara>
-</listitem>
-<listitem>
-<simpara>A term must be a camelCase identifier, ".", or "..".</simpara>
-</listitem>
-<listitem>
-<simpara>Module identifiers may not have file-name extensions like ".js".</simpara>
-</listitem>
-<listitem>
-<simpara>Module identifiers may be "relative" or "top-level". A module
-identifier is "relative" if the first term is "." or "..".</simpara>
-</listitem>
-<listitem>
-<simpara>Top-level identifiers are resolved off the conceptual module
-name space root.</simpara>
-</listitem>
-<listitem>
-<simpara>Relative identifiers are resolved relative to the identifier of
-the module in which "require" is written and called.</simpara>
-</listitem>
-</orderedlist>
-</blockquote>
-</section>
-<section xml:id="sec:Transpilation_Hints">
-<title>Transpilation Hints</title>
-<simpara>This section examines how <literal>Babel</literal> transpiles <literal>ES6</literal> modules to <literal>CommonJS</literal> format. By observing the transpiled output from <literal>Babel</literal>, we can gather insights for transpiling <literal>N4JS</literal> modules to <literal>CommonJS</literal> format.</simpara>
-<section xml:id="sec:Import_Statements">
-<title>Import Statements</title>
-<example>
-<title>Import an entire module (for side effects only)</title>
-<screen>import "B";
-console.log(B);</screen>
-<screen>"use strict";
-
-require("B");
-console.log(B);</screen>
-</example>
-<example>
-<title>Import single member of a module</title>
-<screen>import {b1} from "B";
-b1;</screen>
-<screen>"use strict";
-
-var _B = require("B");
-_B.b1;</screen>
-</example>
-<example>
-<title>Import multiple members of a module</title>
-<screen>import {b1, b2} from "B";
-b1;
-b2;</screen>
-<screen>"use strict";
-
-var _B = require("B");
-
-_B.b1;
-_B.b2;</screen>
-</example>
-<example>
-<title>Import a single member of a module w/ an alias</title>
-<screen>import {b3 as b4} from "B";
-b4 + 1;</screen>
-<screen>"use strict";
-
-var _B = require("B");
-
-_B.b3 + 1;</screen>
-</example>
-<example>
-<title>Import multiple members of a module w/ aliases</title>
-<screen>import {b3 as b4, b5 as b6} from "B";
-b4 + 1;
-b6 + 1;</screen>
-<screen>"use strict";
-
-var _B = require("B");
-
-_B.b3 + 1;
-_B.b5 + 1;</screen>
-</example>
-<example>
-<title>Import ALL the bindings of a module</title>
-<screen>import * as B from "B";
-console.log(B);</screen>
-<screen>"use strict";
-
-function _interopRequireWildcard(obj) {
- //Babel internally tracks ES6 modules using a flag "__esModule".
- if (obj && obj.__esModule) {
- return obj;
- } else {
- //Copy over all the exported members.
- var newObj = {};
- if (obj != null) {
- for (var key in obj) {
- if (Object.prototype.hasOwnProperty.call(obj, key)) newObj[key] = obj[key];
- }
- }
-
- //Set the "default" as the obj itself (ES6 default export)
- newObj["default"] = obj;
- return newObj;
- }
-}
-
-var _B = require("B");
-
-var B = _interopRequireWildcard(_B);
-
-console.log(B);</screen>
-</example>
-<example>
-<title>Import the default export of a module</title>
-<screen>import B from "B";
-console.log(B);</screen>
-<screen>"use strict";
-
-//For importing a default export,
-//Babel checks if the obj is an ES6 module or not.
-function _interopRequireDefault(obj) {
- return obj && obj.__esModule ? obj : { "default": obj };
-}
-
-var _B = require("B");
-
-var _B2 = _interopRequireDefault(_B);
-
-console.log(_B2["default"]);</screen>
-</example>
-</section>
-<section xml:id="sec:Export_Statements">
-<title>Export Statements</title>
-<example>
-<title>Export a member</title>
-<screen>let a = 1;
-export {a};</screen>
-<screen>"use strict";
-
-//Babel makes a note that this is as an ES6 module.
-//This information is later used when this module is imported.
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-var a = 1;
-
-exports.a = a;</screen>
-</example>
-<example>
-<title>Export multiple members</title>
-<screen>let a = 1;
-let b = true;
-
-export {a, b};</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-var a = 1;
-var b = true;
-
-exports.a = a;
-exports.b = b;</screen>
-</example>
-<example>
-<title>Export using alias</title>
-<screen>let a =1;
-export {a as b};</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-var a = 1;
-exports.b = a;</screen>
-</example>
-<example>
-<title>Multiple exports using alias</title>
-<screen>let a = 1, b = 2;
-export {a as A, b as B};</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-var a = 1,
- b = 2;
-exports.A = a;
-exports.B = b;</screen>
-</example>
-<example>
-<title>Simple default export</title>
-<screen>export default 42;</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-exports["default"] = 42; //<-- default export is treated as a special named export
-module.exports = exports["default"]; //<-- IMPORTANT</screen>
-</example>
-<example>
-<title>Default export using an alias</title>
-<screen>let x =10;
-export {x as default};</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-var x = 10;
-exports["default"] = x;
-module.exports = exports["default"];</screen>
-</example>
-<example>
-<title>Default export w/ named export</title>
-<screen>let a = 1;
-export {a};
-export default 42;</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-var a = 1;
-exports.a = a;
-exports["default"] = 42;</screen>
-</example>
-<example>
-<title>Default export a class</title>
-<screen>export default class A {}</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-
-function _classCallCheck(...) { ... }
-
-var A = function A() {
- _classCallCheck(this, A);
-};
-
-exports["default"] = A;
-module.exports = exports["default"];</screen>
-</example>
-<example>
-<title>Wildcard re-export</title>
-<screen>export * from "A"</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-
-function _interopExportWildcard(obj, defaults) {
- var newObj = defaults({}, obj);
- delete newObj["default"]; //<-- A module's default export can not be re-exported.
- return newObj;
-}
-
-function _defaults(obj, defaults) {
- var keys = Object.getOwnPropertyNames(defaults);
- for (var i = 0; i < keys.length; i++) {
- var key = keys[i];
- var value = Object.getOwnPropertyDescriptor(defaults, key);
- if (value && value.configurable && obj[key] === undefined) {
- Object.defineProperty(obj, key, value);
- }
- }
- return obj;
-}
-
-var _A = require("A");
-
-_defaults(exports, _interopExportWildcard(_A, _defaults));</screen>
-</example>
-<example>
-<title>Specific member re-export</title>
-<screen>export {a1, a2} from "A";</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-
-var _A = require("A");
-
-Object.defineProperty(exports, "a1", {
- enumerable: true,
- get: function get() {
- return _A.a1;
- }
-});
-Object.defineProperty(exports, "a2", {
- enumerable: true,
- get: function get() {
- return _A.a2;
- }
-});</screen>
-</example>
-<example>
-<title>Specific member re-export using alias</title>
-<screen>export {a1 as A1, a2 as A2} from "A";</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-
-var _A = require("A");
-
-Object.defineProperty(exports, "A1", {
- enumerable: true,
- get: function get() {
- return _A.a1;
- }
-});
-Object.defineProperty(exports, "A2", {
- enumerable: true,
- get: function get() {
- return _A.a2;
- }
-});</screen>
-</example>
-</section>
-<section xml:id="sec:Tracking_Live_Bindings">
-<title>Tracking Live Bindings</title>
-<simpara>As specified in the section about <literal>ES6 Modules</literal> (<link linkend="sec:ES6_Modules">ES6 Modules</link>), <literal>ES6 Modules</literal> export live immutable bindings. The following listings demonstrate how <literal>Babel</literal> achieves this.</simpara>
-<example>
-<title>Tracking Live Binding</title>
-<screen>export var a = 1;
-a++;</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-var a = 1;
-exports.a = a;
-exports.a = a += 1; //<-- Exported value is tracked.</screen>
-</example>
-</section>
-<section xml:id="sec:A_complete_example">
-<title>A complete example</title>
-<simpara>The following listings present a simple but complete example of ES6 export, import and live-binding concepts. It uses 3 simple <literal>ES6 modules</literal> called <literal>A.js, B.js and Main.js</literal>. The modules are listed alongside their <literal>CommonJS</literal> versions generated by <literal>Babel</literal>.</simpara>
-<informalexample>
-<screen>export var a = 1; //<-- exports a number
-
-export function incA() { //<-- exports a function
- a++;
-}</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-
-exports.incA = incA;
-var a = 1;
-
-exports.a = a;
-
-function incA() {
- exports.a = a += 1;
-}</screen>
-<screen>import {incA} from "./A"; //<-- Imports the function from A.js
-
-export function incB() { //<-- Exports a function that calls the imported function from A.js
- incA();
-}</screen>
-<screen>"use strict";
-
-Object.defineProperty(exports, "__esModule", {
- value: true
-});
-exports.incB = incB;
-
-var _A = require("./A");
-
-function incB() {
- _A.incA();
-}</screen>
-<screen>import {a} from "./A"; //<-- Imports the exported number from A.js
-import {incB} from "./B"; //<-- Imports the exported function from B.js
-
-console.log(a); //<-- Prints "1"
-incB(); //<-- This will call the "incA" function of A.js
-console.log(a); //<--Prints "2". The imported value "a" is updated.</screen>
-<screen>"use strict";
-
-var _A = require("./A");
-
-var _B = require("./B");
-
-console.log(_A.a);
-_B.incB();
-console.log(_A.a);</screen>
-</informalexample>
-</section>
-</section>
-<section xml:id="_resources-2">
-<title>Resources</title>
-<simpara><link xl:href="http://exploringjs.com/es6/ch_modules.html">Exploring ES6 by Dr. Axel Rauschmayer</link></simpara>
-<simpara><link xl:href="http://www.commonjs.org/specs/modules/1.0/">CommonJS spec</link></simpara>
-<simpara><link xl:href="http://benjamn.github.io/empirenode-2015/">The Importance of import and export</link></simpara>
-</section>
-</section>
-</appendix>
-<appendix xml:id="sec:License">
-<title>License</title>
-<simpara>This specification and the accompanying materials is made available
-under the terms of the Eclipse Public License v1.0 which accompanies
-this distribution, and is available at <link xl:href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</link></simpara>
-<bridgehead xml:id="_eclipse-public-license-v-1-0" renderas="sect2">Eclipse Public License - v 1.0</bridgehead>
-<simpara>THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE
-PUBLIC LICENSE (<literal>AGREEMENT</literal>). ANY USE, REPRODUCTION OR DISTRIBUTION OF
-THE PROGRAM CONSTITUTES RECIPIENT’S ACCEPTANCE OF THIS AGREEMENT.</simpara>
-<bridgehead xml:id="_1-definitions" renderas="sect3">1. DEFINITIONS</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>Contribution</literal> means: </term>
-<listitem>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>in the case of the initial Contributor, the initial code and
-documentation distributed under this Agreement, and</simpara>
-</listitem>
-<listitem>
-<simpara>in the case of each subsequent Contributor:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>changes to the Program, and</simpara>
-</listitem>
-<listitem>
-<simpara>additions to the Program;</simpara>
-<simpara>where such changes and/or additions to the Program originate from and
-are distributed by that particular Contributor. A Contribution
-’originates’ from a Contributor if it was added to the Program by such
-Contributor itself or anyone acting on such Contributor’s behalf.
-Contributions do not include additions to the Program which:</simpara>
-<orderedlist numeration="lowerroman">
-<listitem>
-<simpara>are separate modules of software distributed in conjunction with the Program
-under their own license agreement, and</simpara>
-</listitem>
-<listitem>
-<simpara>are not derivative works of the Program.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Contributor</literal></term>
-<listitem>
-<simpara>means any person or entity that distributes the Program.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Licensed Patents</literal> </term>
-<listitem>
-<simpara>mean patent claims licensable by a Contributor
-which are necessarily infringed by the use or sale of its Contribution
-alone or when combined with the Program.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Program</literal> </term>
-<listitem>
-<simpara>means the Contributions distributed in accordance with this
-Agreement.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Recipient</literal> </term>
-<listitem>
-<simpara>means anyone who receives the Program under this
-Agreement, including all Contributors.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="_2-grant-of-rights" renderas="sect3">2. GRANT OF RIGHTS</bridgehead>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Subject to the terms of this Agreement, each Contributor hereby
-grants Recipient a non-exclusive, worldwide, royalty-free copyright
-license to reproduce, prepare derivative works of, publicly display,
-publicly perform, distribute and sublicense the Contribution of such
-Contributor, if any, and such derivative works, in source code and
-object code form.</simpara>
-</listitem>
-<listitem>
-<simpara>Subject to the terms of this Agreement, each Contributor hereby
-grants Recipient a non-exclusive, worldwide, royalty-free patent license
-under Licensed Patents to make, use, sell, offer to sell, import and
-otherwise transfer the Contribution of such Contributor, if any, in
-source code and object code form. This patent license shall apply to the
-combination of the Contribution and the Program if, at the time the
-Contribution is added by the Contributor, such addition of the
-Contribution causes such combination to be covered by the Licensed
-Patents. The patent license shall not apply to any other combinations
-which include the Contribution. No hardware per se is licensed
-hereunder.</simpara>
-</listitem>
-<listitem>
-<simpara>Recipient understands that although each Contributor grants the
-licenses to its Contributions set forth herein, no assurances are
-provided by any Contributor that the Program does not infringe the
-patent or other intellectual property rights of any other entity. Each
-Contributor disclaims any liability to Recipient for claims brought by
-any other entity based on infringement of intellectual property rights
-or otherwise. As a condition to exercising the rights and licenses
-granted hereunder, each Recipient hereby assumes sole responsibility to
-secure any other intellectual property rights needed, if any. For
-example, if a third party patent license is required to allow Recipient
-to distribute the Program, it is Recipient’s responsibility to acquire
-that license before distributing the Program.</simpara>
-</listitem>
-<listitem>
-<simpara>Each Contributor represents that to its knowledge it has sufficient
-copyright rights in its Contribution, if any, to grant the copyright
-license set forth in this Agreement.</simpara>
-</listitem>
-</orderedlist>
-<bridgehead xml:id="_3-requirements" renderas="sect3">3. REQUIREMENTS</bridgehead>
-<simpara>A Contributor may choose to distribute the Program in object code form
-under its own license agreement, provided that:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>it complies with the terms and conditions of this Agreement; and</simpara>
-</listitem>
-<listitem>
-<simpara>its license agreement:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>effectively disclaims on behalf of all Contributors all warranties
-and conditions, express and implied, including warranties or conditions
-of title and non-infringement, and implied warranties or conditions of
-merchantability and fitness for a particular purpose;</simpara>
-</listitem>
-<listitem>
-<simpara>effectively excludes on behalf of all Contributors all liability for
-damages, including direct, indirect, special, incidental and
-consequential damages, such as lost profits;</simpara>
-</listitem>
-<listitem>
-<simpara>states that any provisions which differ from this Agreement are
-offered by that Contributor alone and not by any other party; and</simpara>
-</listitem>
-<listitem>
-<simpara>states that source code for the Program is available from such
-Contributor, and informs licensees how to obtain it in a reasonable
-manner on or through a medium customarily used for software exchange.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-<simpara>When the Program is made available in source code form:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>it must be made available under this Agreement; and</simpara>
-</listitem>
-<listitem>
-<simpara>a copy of this Agreement must be included with each copy of the
-Program.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Contributors may not remove or alter any copyright notices contained
-within the Program.</simpara>
-<simpara>Each Contributor must identify itself as the originator of its
-Contribution, if any, in a manner that reasonably allows subsequent
-Recipients to identify the originator of the Contribution.</simpara>
-<bridgehead xml:id="_4-commercial-distribution" renderas="sect3">4. COMMERCIAL DISTRIBUTION</bridgehead>
-<simpara>Commercial distributors of software may accept certain responsibilities
-with respect to end users, business partners and the like. While this
-license is intended to facilitate the commercial use of the Program, the
-Contributor who includes the Program in a commercial product offering
-should do so in a manner which does not create potential liability for
-other Contributors. Therefore, if a Contributor includes the Program in
-a commercial product offering, such Contributor (<literal>Commercial
-Contributor</literal>) hereby agrees to defend and indemnify every other
-Contributor (<literal>Indemnified Contributor</literal>) against any losses, damages
-and costs (collectively <literal>Losses</literal>) arising from claims, lawsuits and
-other legal actions brought by a third party against the Indemnified
-Contributor to the extent caused by the acts or omissions of such
-Commercial Contributor in connection with its distribution of the
-Program in a commercial product offering. The obligations in this
-section do not apply to any claims or Losses relating to any actual or
-alleged intellectual property infringement. In order to qualify, an
-Indemnified Contributor must: a) promptly notify the Commercial
-Contributor in writing of such claim, and b) allow the Commercial
-Contributor to control, and cooperate with the Commercial Contributor
-in, the defense and any related settlement negotiations. The Indemnified
-Contributor may participate in any such claim at its own expense.</simpara>
-<simpara>For example, a Contributor might include the Program in a commercial
-product offering, Product X. That Contributor is then a Commercial
-Contributor. If that Commercial Contributor then makes performance
-claims, or offers warranties related to Product X, those performance
-claims and warranties are such Commercial Contributor’s responsibility
-alone. Under this section, the Commercial Contributor would have to
-defend claims against the other Contributors related to those
-performance claims and warranties, and if a court requires any other
-Contributor to pay any damages as a result, the Commercial Contributor
-must pay those damages.</simpara>
-<bridgehead xml:id="_5-no-warranty" renderas="sect3">5. NO WARRANTY</bridgehead>
-<simpara>EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED
-ON AN <literal>AS IS</literal> BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
-EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES
-OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR
-A PARTICULAR PURPOSE. Each Recipient is solely responsible for
-determining the appropriateness of using and distributing the Program
-and assumes all risks associated with its exercise of rights under this
-Agreement , including but not limited to the risks and costs of program
-errors, compliance with applicable laws, damage to or loss of data,
-programs or equipment, and unavailability or interruption of operations.</simpara>
-<bridgehead xml:id="_6-disclaimer-of-liability" renderas="sect3">6. DISCLAIMER OF LIABILITY</bridgehead>
-<simpara>EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR
-ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT,
-INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING
-WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF
-LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
-NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR
-DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
-HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</simpara>
-<bridgehead xml:id="_7-general" renderas="sect3">7. GENERAL</bridgehead>
-<simpara>If any provision of this Agreement is invalid or unenforceable under
-applicable law, it shall not affect the validity or enforceability of
-the remainder of the terms of this Agreement, and without further action
-by the parties hereto, such provision shall be reformed to the minimum
-extent necessary to make such provision valid and enforceable.</simpara>
-<simpara>If Recipient institutes patent litigation against any entity (including
-a cross-claim or counterclaim in a lawsuit) alleging that the Program
-itself (excluding combinations of the Program with other software or
-hardware) infringes such Recipient’s patent(s), then such Recipient’s
-rights granted under Section 2(b) shall terminate as of the date such
-litigation is filed.</simpara>
-<simpara>All Recipient’s rights under this Agreement shall terminate if it fails
-to comply with any of the material terms or conditions of this Agreement
-and does not cure such failure in a reasonable period of time after
-becoming aware of such noncompliance. If all Recipient’s rights under
-this Agreement terminate, Recipient agrees to cease use and distribution
-of the Program as soon as reasonably practicable. However, Recipient’s
-obligations under this Agreement and any licenses granted by Recipient
-relating to the Program shall continue and survive.</simpara>
-<simpara>Everyone is permitted to copy and distribute copies of this Agreement,
-but in order to avoid inconsistency the Agreement is copyrighted and may
-only be modified in the following manner. The Agreement Steward reserves
-the right to publish new versions (including revisions) of this
-Agreement from time to time. No one other than the Agreement Steward has
-the right to modify this Agreement. The Eclipse Foundation is the
-initial Agreement Steward. The Eclipse Foundation may assign the
-responsibility to serve as the Agreement Steward to a suitable separate
-entity. Each new version of the Agreement will be given a distinguishing
-version number. The Program (including Contributions) may always be
-distributed subject to the version of the Agreement under which it was
-received. In addition, after a new version of the Agreement is
-published, Contributor may elect to distribute the Program (including
-its Contributions) under the new version. Except as expressly stated in
-Sections 2(a) and 2(b) above, Recipient receives no rights or licenses
-to the intellectual property of any Contributor under this Agreement,
-whether expressly, by implication, estoppel or otherwise. All rights in
-the Program not expressly granted under this Agreement are reserved.</simpara>
-<simpara>This Agreement is governed by the laws of the State of New York and the
-intellectual property laws of the United States of America. No party to
-this Agreement will bring a legal action under this Agreement more than
-one year after the cause of action arose. Each party waives its rights
-to a jury trial in any resulting litigation.</simpara>
-</appendix>
-<appendix xml:id="sec:Acronyms">
-<title>Acronyms</title>
-<informaltable xml:id="AC" role="language-bash" frame="all" rowsep="1" colsep="1">
-<tgroup cols="4">
-<colspec colname="col_1" colwidth="12.5*"/>
-<colspec colname="col_2" colwidth="37.5*"/>
-<colspec colname="col_3" colwidth="12.5*"/>
-<colspec colname="col_4" colwidth="37.5*"/>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><literal>CDep</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Compile-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>RDep</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Run-Time Dependency</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>LDep</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Load-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>IDep</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Initialization-Time Dependency</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>EDep</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Execution-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>AC</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Acceptance Criteria</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>ANTLR</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">ANother Tool for Language Recognition</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>API</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Application Programming Interface</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>AST</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Abstract Syntax Tree</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>ASI</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Automatic Semicolon Insertion</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>AST</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Abstract Syntax Tree</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>BNF</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Backus-Naur Form</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>CA</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Content-Assist</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>CSP</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Constraint Satisfaction Problem</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>CLI</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Command Line Interface</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>DOM</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Document Object Model</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>DSL</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Domain Specific Language</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>EBNF</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Extended Backus-Naur Form</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>EMF</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Eclipse Modeling Framework</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>EPL</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Eclipse Public License</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>FQN</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Fully Qualified Name</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>GLB</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Greatest Lower Bound, also known as <emphasis role="strong">infimum</emphasis></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>GPL</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">GNU General Public License</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>IDE</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Integrated Development Environment</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>IDL</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Interface Definition Language</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>LSP</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Liskov Substitution Principle</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>LUB</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Least Upper Bound, also known as <emphasis role="strong">supremum</emphasis></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>N4JS</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">NumberFour JavaScript</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>UI</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">User Interface</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>UML</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Unified Modeling Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>VM</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Virtual Machine</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>XML</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Extensible Markup Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>XSLT</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong"><link linkend="XSL">XSL</link> Transformations</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>XSL <anchor xml:id="XSL" xreflabel="[XSL]"/></literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Extensible Stylesheet Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>WYSIWYG</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">What You See Is What You Get</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>WLOG</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">without loss of generality</emphasis></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</appendix>
-<appendix xml:id="_bibliography-and-footnotes">
-<title>Bibliography and Footnotes</title>
-<simpara><anchor xml:id="N4JSSpec" xreflabel="[N4JSSpec]"/>N4JS Project. (2018). <emphasis>N4JS Language Specification</emphasis>. Retrieved from <link xl:href="https://www.eclipse.org/n4js/spec/N4JSSpec.html">https://www.eclipse.org/n4js/spec/N4JSSpec.html</link></simpara>
-<simpara><anchor xml:id="Xpect" xreflabel="[Xpect]"/><emphasis>Xpect, Project Website</emphasis>. Retrieved from <link xl:href="https://projects.eclipse.org/projects/modeling.xpect">https://projects.eclipse.org/projects/modeling.xpect</link></simpara>
-<simpara><anchor xml:id="RFC8259" xreflabel="[RFC8259]"/>Bray, Tim. (2017). <emphasis>RFC 8259: The javascript object notation (json) data interchange format</emphasis>. </simpara>
-<simpara><anchor xml:id="ECMA404" xreflabel="[ECMA404]"/>International, ECMA. (2017). <emphasis>Standard ECMA-404, The JSON Data Interchange Syntax</emphasis>. </simpara>
-<simpara><anchor xml:id="RFC7158" xreflabel="[RFC7158]"/>Bray, Tim. (2014). <emphasis>RFC 7158: The JavaScript Object Notation ({JSON}) Data Interchange Format</emphasis>. </simpara>
-<simpara><anchor xml:id="Ser18" xreflabel="[Ser18]"/>Seriot, Nicolas. (2018). <emphasis>Parsing JSON is a Minefield</emphasis>. Retrieved from <link xl:href="http://seriot.ch/parsing_json.php">http://seriot.ch/parsing_json.php</link></simpara>
-<simpara><anchor xml:id="ECMA15a" xreflabel="[ECMA15a]"/>ECMA. (2015). <emphasis>ECMAScript 2015 Language Specification</emphasis>. Retrieved from <link xl:href="http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf">http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf</link></simpara>
-<simpara><anchor xml:id="WhatWGLoader" xreflabel="[WhatWGLoader]"/>WhatWG. <emphasis>Loader: A Collection of Interesting Ideas</emphasis>. Retrieved from <link xl:href="http://whatwg.github.io/loader/">http://whatwg.github.io/loader/</link></simpara>
-</appendix>
-</book>
\ No newline at end of file
diff --git a/design/appendix_a_hints.html b/design/appendix_a_hints.html
index fdcf51d..04b8547 100644
--- a/design/appendix_a_hints.html
+++ b/design/appendix_a_hints.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1288,7 +1288,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/appendix_b_module_loading.html b/design/appendix_b_module_loading.html
index c1b6a6e..3b75ba4 100644
--- a/design/appendix_b_module_loading.html
+++ b/design/appendix_b_module_loading.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -3863,7 +3863,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/appendix_c_license.html b/design/appendix_c_license.html
index abd7567..8e4ee73 100644
--- a/design/appendix_c_license.html
+++ b/design/appendix_c_license.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1156,7 +1156,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/appendix_d_acronyms.html b/design/appendix_d_acronyms.html
index 768b3d9..955c7cf 100644
--- a/design/appendix_d_acronyms.html
+++ b/design/appendix_d_acronyms.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -976,7 +976,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/appendix_e_bibliography_and_footnotes.html b/design/appendix_e_bibliography_and_footnotes.html
index 40b3f2f..c20043d 100644
--- a/design/appendix_e_bibliography_and_footnotes.html
+++ b/design/appendix_e_bibliography_and_footnotes.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -943,7 +943,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/binding.html b/design/binding.html
index c549025..1b333d4 100644
--- a/design/binding.html
+++ b/design/binding.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1328,7 +1328,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/compilation.html b/design/compilation.html
index 8318e90..79393f4 100644
--- a/design/compilation.html
+++ b/design/compilation.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1853,7 +1853,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/docexporter.html b/design/docexporter.html
index faa00c7..ff81385 100644
--- a/design/docexporter.html
+++ b/design/docexporter.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -915,7 +915,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/eclipse_setup.html b/design/eclipse_setup.html
index bac3e4f..c2db829 100644
--- a/design/eclipse_setup.html
+++ b/design/eclipse_setup.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -879,7 +879,7 @@
<p>change to "Advance Mode" via the menu (upper-right corner) (no need to move the installer)</p>
</li>
<li>
-<p>select a product, e.g. "Eclipse IDE for Eclipse Committers" with product version "latest"</p>
+<p>select a product, e.g. "Eclipse IDE for Eclipse Committers" with product version "2019-06". Hint: Do not select "latest" because this will cause automatic updates which may lead to weird errors later on.</p>
</li>
<li>
<p>double-click the entry <strong>Eclipse Projects/N4JS</strong> so that it is shown in the catalog view below</p>
@@ -900,7 +900,7 @@
</div>
<div class="paragraph">
<p>Eventually the installer scripts are done, that means the git repository has been cloned and the workspace has been configured (including the project set setup).
-Now the automatic build kicks in as you can see in the status bar. Screenshot 6</p>
+Now the automatic build kicks in as you can see in the status bar.</p>
</div>
<div class="paragraph">
<p>The build will show a lot of errors while still working. Eventually the whole project should have been compiled without any errors. Unfortunately, due to a <a href="https://github.com/eclipse/n4js/issues/1373">known issue</a>, two problems exists. Please have a look at the linked issue on how to fix that (it is quite easy).</p>
@@ -980,7 +980,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/execution.html b/design/execution.html
index 20ec1ae..ef8ce43 100644
--- a/design/execution.html
+++ b/design/execution.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1311,7 +1311,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/external_libraries.html b/design/external_libraries.html
index 9634018..32a0400 100644
--- a/design/external_libraries.html
+++ b/design/external_libraries.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1205,7 +1205,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/flow_graphs.html b/design/flow_graphs.html
index 462102e..7988434 100644
--- a/design/flow_graphs.html
+++ b/design/flow_graphs.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1384,7 +1384,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/formatting.html b/design/formatting.html
index 1ca41ac..0bce8ff 100644
--- a/design/formatting.html
+++ b/design/formatting.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1066,7 +1066,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/index.html b/design/index.html
index ddffdae..78e0394 100644
--- a/design/index.html
+++ b/design/index.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -853,7 +853,7 @@
<div id="preamble">
<div class="sectionbody">
<div class="paragraph center">
-<p><strong>Last Updated: 2019-08-07</strong></p>
+<p><strong>Last Updated: 2019-08-08</strong></p>
</div>
<div class="paragraph center">
<p><strong>Authors:</strong><br>
@@ -927,7 +927,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/introduction.html b/design/introduction.html
index b4446a2..4239780 100644
--- a/design/introduction.html
+++ b/design/introduction.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1315,7 +1315,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/jsdoc.html b/design/jsdoc.html
index 93baa07..9e1355b 100644
--- a/design/jsdoc.html
+++ b/design/jsdoc.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -927,7 +927,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/json_support.html b/design/json_support.html
index ec0d8ce..43bf2bb 100644
--- a/design/json_support.html
+++ b/design/json_support.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -970,7 +970,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/parser.html b/design/parser.html
index fb7f308..14e6aa8 100644
--- a/design/parser.html
+++ b/design/parser.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1098,7 +1098,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/project_model.html b/design/project_model.html
index 053a621..e0a4b7c 100644
--- a/design/project_model.html
+++ b/design/project_model.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1067,7 +1067,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/publish_npms.html b/design/publish_npms.html
index 5f425fc..80ea17c 100644
--- a/design/publish_npms.html
+++ b/design/publish_npms.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -981,7 +981,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/references.html b/design/references.html
index c55f583..75924a4 100644
--- a/design/references.html
+++ b/design/references.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1475,7 +1475,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/release_engineering.html b/design/release_engineering.html
index 8f98ae5..9472fa0 100644
--- a/design/release_engineering.html
+++ b/design/release_engineering.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1333,7 +1333,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/rename_refactoring.html b/design/rename_refactoring.html
index 8b84478..d40f571 100644
--- a/design/rename_refactoring.html
+++ b/design/rename_refactoring.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -934,7 +934,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/tests.html b/design/tests.html
index e9d877f..0d5494e 100644
--- a/design/tests.html
+++ b/design/tests.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -3275,7 +3275,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/tips_and_tricks.html b/design/tips_and_tricks.html
index bf408d1..436cf25 100644
--- a/design/tips_and_tricks.html
+++ b/design/tips_and_tricks.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1083,7 +1083,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/type_index.html b/design/type_index.html
index 272949d..e3b40cb 100644
--- a/design/type_index.html
+++ b/design/type_index.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -2112,7 +2112,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/type_system.html b/design/type_system.html
index 643f3ad..abb4e51 100644
--- a/design/type_system.html
+++ b/design/type_system.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1465,7 +1465,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/ui_concepts.html b/design/ui_concepts.html
index 639b43b..d89ca82 100644
--- a/design/ui_concepts.html
+++ b/design/ui_concepts.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -2242,7 +2242,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/design/validation.html b/design/validation.html
index e2e59a1..2e60fcb 100644
--- a/design/validation.html
+++ b/design/validation.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Design Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Design Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1365,7 +1365,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/N4JSIDESpec.html b/idespec/N4JSIDESpec.html
index e94e76b..08d8352 100644
--- a/idespec/N4JSIDESpec.html
+++ b/idespec/N4JSIDESpec.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -289,7 +289,7 @@
<div id="preamble">
<div class="sectionbody">
<div class="paragraph center">
-<p><strong>Last Updated: 2019-08-07</strong></p>
+<p><strong>Last Updated: 2019-08-08</strong></p>
</div>
<div class="paragraph center">
<p><strong>Authors:</strong><br>
@@ -2271,7 +2271,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Project constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413a"></a><strong>Req. GH-1413a:</strong> <a href="#Req-GH-1413a">Project constraints</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -2299,7 +2299,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Project browse button</a> (ver. 1)</p>
+<p><a id="Req-GH-1413b"></a><strong>Req. GH-1413b:</strong> <a href="#Req-GH-1413b">Project browse button</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2314,7 +2314,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Project initial selection inference</a> (ver. 1)</p>
+<p><a id="Req-GH-1413c"></a><strong>Req. GH-1413c:</strong> <a href="#Req-GH-1413c">Project initial selection inference</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2329,7 +2329,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Project content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413d"></a><strong>Req. GH-1413d:</strong> <a href="#Req-GH-1413d">Project content assist</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2352,7 +2352,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Source folder constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413e"></a><strong>Req. GH-1413e:</strong> <a href="#Req-GH-1413e">Source folder constraints</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -2388,7 +2388,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Source folder browse button</a> (ver. 1)</p>
+<p><a id="Req-GH-1413f"></a><strong>Req. GH-1413f:</strong> <a href="#Req-GH-1413f">Source folder browse button</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2403,7 +2403,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Source folder initial selection inference</a> (ver. 1)</p>
+<p><a id="Req-GH-1413g"></a><strong>Req. GH-1413g:</strong> <a href="#Req-GH-1413g">Source folder initial selection inference</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2418,7 +2418,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Source folder content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413h"></a><strong>Req. GH-1413h:</strong> <a href="#Req-GH-1413h">Source folder content assist</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2441,7 +2441,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413i"></a><strong>Req. GH-1413i:</strong> <a href="#Req-GH-1413i">Module specifier constraints</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>The specifier is a valid module specifier that is
@@ -2453,7 +2453,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier completion</a> (ver. 1)</p>
+<p><a id="Req-GH-1413j"></a><strong>Req. GH-1413j:</strong> <a href="#Req-GH-1413j">Module specifier completion</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Manually inserting a specifier ending with a separator is valid.
@@ -2464,7 +2464,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier grey suffix</a> (ver. 1)</p>
+<p><a id="Req-GH-1413k"></a><strong>Req. GH-1413k:</strong> <a href="#Req-GH-1413k">Module specifier grey suffix</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>A grey suffix should suggest the attached class name as module name if the specifier only specifies a base path.</p>
@@ -2474,7 +2474,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier browse button</a> (ver. 1)</p>
+<p><a id="Req-GH-1413l"></a><strong>Req. GH-1413l:</strong> <a href="#Req-GH-1413l">Module specifier browse button</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Browsing only allows the selection of modules or module containers in the selected source folder. The browse dialog has to offer a module container creation functionality. In contrast to the other parts of the wizard, the creation of module containers in this dialog should be immediate and on file system level. This is important to comply with the conceptual model of eclipse and the operating system.</p>
@@ -2487,7 +2487,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier initial selection inference</a> (ver. 1)</p>
+<p><a id="Req-GH-1413m"></a><strong>Req. GH-1413m:</strong> <a href="#Req-GH-1413m">Module specifier initial selection inference</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>The module specifier should be derived from the initial selection by using the container of the selection as initial module container</p>
@@ -2497,7 +2497,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413n"></a><strong>Req. GH-1413n:</strong> <a href="#Req-GH-1413n">Module specifier content assist</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Modules in the selected source folder</p>
@@ -2518,7 +2518,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Class name basic constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413o"></a><strong>Req. GH-1413o:</strong> <a href="#Req-GH-1413o">Class name basic constraints</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -2546,7 +2546,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Class name conflict validation</a> (ver. 1)</p>
+<p><a id="Req-GH-1413p"></a><strong>Req. GH-1413p:</strong> <a href="#Req-GH-1413p">Class name conflict validation</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>If the target module already exists no other type with the same identifier may exist in this module</p>
@@ -2556,7 +2556,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">File type options</a> (ver. 1)</p>
+<p><a id="Req-GH-1413q"></a><strong>Req. GH-1413q:</strong> <a href="#Req-GH-1413q">File type options</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2571,7 +2571,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Access modifier constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413r"></a><strong>Req. GH-1413r:</strong> <a href="#Req-GH-1413r">Access modifier constraints</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Specifies the access modifiers of the class. One of <code>public</code>, <code>project</code>, <strong>private</strong>. <code>@Internal</code> is an additionally selectable option.</p>
@@ -2610,7 +2610,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Other modifiers constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413s"></a><strong>Req. GH-1413s:</strong> <a href="#Req-GH-1413s">Other modifiers constraints</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2639,7 +2639,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Super class constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413t"></a><strong>Req. GH-1413t:</strong> <a href="#Req-GH-1413t">Super class constraints</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -2664,7 +2664,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Super class browse button</a> (ver. 1)</p>
+<p><a id="Req-GH-1413u"></a><strong>Req. GH-1413u:</strong> <a href="#Req-GH-1413u">Super class browse button</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -2683,7 +2683,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Super class content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413v"></a><strong>Req. GH-1413v:</strong> <a href="#Req-GH-1413v">Super class content assist</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2706,7 +2706,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Interfaces constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413w"></a><strong>Req. GH-1413w:</strong> <a href="#Req-GH-1413w">Interfaces constraints</a> (ver. 1)</p>
</div>
<div class="olist arabic">
<ol class="arabic">
@@ -2720,7 +2720,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Interfaces browsing</a> (ver. 1)</p>
+<p><a id="Req-GH-1413x"></a><strong>Req. GH-1413x:</strong> <a href="#Req-GH-1413x">Interfaces browsing</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -2739,7 +2739,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Interfaces content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413y"></a><strong>Req. GH-1413y:</strong> <a href="#Req-GH-1413y">Interfaces content assist</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Text input is available by clicking in empty space at the end of the list. Content Assist provides all interfaces matching mentioned criteria.</p>
@@ -2749,7 +2749,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Create method stubs</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z1"></a><strong>Req. GH-1413z1:</strong> <a href="#Req-GH-1413z1">Create method stubs</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Specifies if the wizard should generate method stubs for all abstract methods of the newly generated class. That are abstract super class methods or methods that need to be implemented by the class to conform to the selected interfaces.</p>
@@ -2759,7 +2759,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Create method stub conflict detection</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z2"></a><strong>Req. GH-1413z2:</strong> <a href="#Req-GH-1413z2">Create method stub conflict detection</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>If the selected interfaces are impossible to implement (e.g. method name overlap with unrelated parameter types) this option needs to be disabled and a warning needs to be shown.</p>
@@ -2775,13 +2775,13 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Visibility issue conflict solving</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z3"></a><strong>Req. GH-1413z3:</strong> <a href="#Req-GH-1413z3">Visibility issue conflict solving</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>By allowing the user to select invisible interfaces and super classes or unextendable <code>@Final</code>-annotated super classes, accessability issues may come up. The goal is to never generate a file containing invalid code. To accomplish this, conflicts must get solved before the file is generated.</p>
</div>
<div class="paragraph">
-<p>The slight limitation of the selection of interfaces and classes to elements from modifiable sources (cf. <a href="#Req-GH-1413">super class browse button</a>) allows to solve all possibly occurring visibility issues.</p>
+<p>The slight limitation of the selection of interfaces and classes to elements from modifiable sources (cf. <a href="#Req-GH-1413u">super class browse button</a>) allows to solve all possibly occurring visibility issues.</p>
</div>
<div class="paragraph">
<p>If the modifications by finishing the wizard do imply changes different from insertions and creations, a compare view is to be shown, giving the user an overview of the needed changes before they’re applied.</p>
@@ -2794,7 +2794,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Wizard generation</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z4"></a><strong>Req. GH-1413z4:</strong> <a href="#Req-GH-1413z4">Wizard generation</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>The following changes are to be made by the wizard:</p>
@@ -2826,7 +2826,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Generation preview</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z5"></a><strong>Req. GH-1413z5:</strong> <a href="#Req-GH-1413z5">Generation preview</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>On the right of the wizard form a preview window should be provided. It should preview the full path of the generated file and all code that is generated with the options of the wizard. Changes should be updated in realtime as the user is choosing different options.</p>
@@ -2923,7 +2923,7 @@
</table>
</div>
<div class="paragraph">
-<p>See <a href="#Req-GH-1413">N4JS Class Wizard Modifier Field</a> except for the following point:</p>
+<p>See <a href="#Req-GH-1413r">N4JS Class Wizard Modifier Field</a> except for the following point:</p>
</div>
<div class="paragraph">
<p><em>Other than classes, interfaces must not be declared as <code>@Final</code>, therefore this option is removed.</em></p>
@@ -2967,7 +2967,7 @@
<h4 id="import-naming-conflicts"><a class="anchor" href="#import-naming-conflicts"></a><a class="link" href="#import-naming-conflicts">4.4.3. Import naming conflicts</a></h4>
<div class="paragraph">
<p>As the user may select identically named interfaces, the wizard has to solve these naming conflicts. See
-<strong><a href="#Req-GH-1413">Class Wizard Visibility Issues</a></strong> for details.</p>
+<strong><a href="#Req-GH-1413z3">Class Wizard Visibility Issues</a></strong> for details.</p>
</div>
</div>
<div class="sect3">
@@ -5828,7 +5828,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/N4JSIDESpec.xml b/idespec/N4JSIDESpec.xml
deleted file mode 100644
index 5efd4fc..0000000
--- a/idespec/N4JSIDESpec.xml
+++ /dev/null
@@ -1,4774 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<?asciidoc-toc maxdepth="5"?>
-<?asciidoc-numbered maxdepth="5"?>
-<book xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
-<info>
-<title>N4JS IDE Specification</title>
-<date>2019-08-07</date>
-<author>
-<personname>
-<firstname>2019-08-07 15:02:40 CEST</firstname>
-</personname>
-</author>
-<authorinitials>{</authorinitials>
-<style>
- .admonitionblock td.icon .icon-todo:before{content:"\f249";color:#f4ee42}
- </style>
-</info>
-<preface>
-<title></title>
-<simpara role="center"><emphasis role="strong">Last Updated: 2019-08-07</emphasis></simpara>
-<simpara role="center"><emphasis role="strong">Authors:</emphasis><?asciidoc-br?>
-Jens von Pilgrim, Jakub Siberski, Mark-Oliver Reiser, Torsten Krämer, Ákos Kitta, Sebastian Zarnekow, Lorenzo Bettini, Jörg Reichert, Kristian Duske, Marcus Mews, Minh Quang Tran, Luca Beurer-Kellner</simpara>
-<simpara><?asciidoc-pagebreak?></simpara>
-<bridgehead xml:id="_abstract" renderas="sect1">Abstract</bridgehead>
-<simpara>This document contains the N4JS IDE Specification.</simpara>
-<bridgehead xml:id="_introduction" renderas="sect1">Introduction</bridgehead>
-<simpara>This document describes the features of the N4JS <link linkend="AC">IDE</link>, that is the user interface and features available to users of the <link linkend="AC">IDE</link>. The language N4JS is described in [<link linkend="N4JSSpec">N4JSSpec</link>] and is not part of this document.</simpara>
-</preface>
-<chapter xml:id="sec:Views">
-<title>Views</title>
-<simpara>This section briefly introduces all the views that belong to the application’s default perspective.</simpara>
-<section xml:id="_eclipse-standard-views">
-<title>Eclipse Standard Views</title>
-<simpara>In the following we descibe views usually available in Eclipse based IDEs. Some of the views were slightly adjusted to match specific N4JS needs.</simpara>
-<section xml:id="sec:Project_Explorer_View">
-<title>Project Explorer</title>
-<simpara>The Project Explorer view shows the resources from the underlying workspace in a hierarchical way. From this view one can open a resource for editing in the associated editor or select it to perform an operation on the resource. A popup contest menu is available from the Project Explorer for each resources if used right clicks any of them. A lot of convenient actions are available for from the popping context menu: file modifications (such as Copy, Cut, Paste and Delete) and import/export. Project Explorer support file system modifications by drag-and-dropping resources. One can link the Project Explorer with the editors, if one enables the view-editor-linking then the node in the tree representing a particular resource in the workspace will be automatically revealed and highlighted once one activates the corresponding editor. This works the other way around as well, when a node is selected in the tree and the corresponding resource is opened in an editor, then the editor will be activated.</simpara>
-</section>
-<section xml:id="sec:Outline_View">
-<title>Outline</title>
-<simpara>The Outline view is responsible for displaying the outline of a structured file that is currently opened in an editor. In case of opening an N4JS file the view depicts all the types defined in the file. The owned members, functions and methods of a particular type are represented in a tree structure. Furthermore in case of opening an N4JS file in the editor, one can link the Outline view with the editor which means whenever one selects a node from the outline view the corresponding item will be revealed and highlighted in the editor.</simpara>
-</section>
-<section xml:id="sec:Problems_View">
-<title>Problems</title>
-<simpara>This view is used to show all validation errors and warnings in a table that are generated for workbench resources such as N4JS files. For instance when one writes and/or saves an N4JS file that contains validation errors and/or warnings those issues will be automatically logged into the Problems view. One can reveal the actual problem in the N4JS by simply double-clicking on the problem in the view. In this case the corresponding N4JS file will be opened (if it was not already opened), activated and the relevant line will be revealed in the editor. By default the grouping in the Problems view is done by the severity of the issues. One can group the issues by issue type or just disable the grouping at all. The first column of the table is the actual description of the issue for a particular resource. The second column names the problematic resource itself. The third column shows the relative path of the problematic resource. The location, fifth, column describes the problematic line in the resource. And last but not least the sixth column is for naming the type of the problem. This is optional and might be missing for some cases. One can customise the content of the view from the view menu. One can limit the number of revealed items in the table or can modify the behaviour of the content provider.</simpara>
-</section>
-<section xml:id="sec:Console_View">
-<title>Console</title>
-<simpara>The Console view is used to reveal a text based output provided by a running process and also allows user to provide any input to the running process from the keyboard.</simpara>
-</section>
-<section xml:id="sec:History_View">
-<title>History</title>
-<simpara>History view supports a way to track the changes of the workbench resources. This view also responsible for providing a convenient way to reveal historical revisions of a particular resource and it is even supports a mechanism to compare two different revisions of a resource. By default this view only provides local historical information but if a resource is under version control then one can retrieve revisions for that particular resource even it was made by remotely by another IDE user.</simpara>
-</section>
-<section xml:id="sec:Error_Log_View">
-<title>Error Log</title>
-<simpara>The Error Log view captures and logs all errors and warnings in a table generated by the application itself. Unlike Problems view the Error Log is responsible to collect and to reveal issues caused by a malfunctioned component or module of the IDE.</simpara>
-</section>
-</section>
-<section xml:id="_n4js-specific-views">
-<title>N4JS Specific Views</title>
-<simpara>The following views are specific to N4JS. Some of these views are useful for developers of the N4JS language itself as they reveal internal details at runtime. Most of these views can be opened via <literal>Windows/Show View/Other..</literal>, see <literal>N4JS</literal> category.</simpara>
-<section xml:id="_test-results">
-<title>Test Results</title>
-<simpara>The N4JS equivalent to the JUnit test view.</simpara>
-</section>
-<section xml:id="_source-graphs">
-<title>Source Graphs</title>
-<simpara>Shows the AST of the current source code in the editor windows.</simpara>
-</section>
-<section xml:id="_api-compare">
-<title>API Compare</title>
-<simpara>Shows compare results, i.e. the difference between an API definition project and its implementation.</simpara>
-</section>
-<section xml:id="_performance-graphs">
-<title>Performance Graphs</title>
-<simpara>Shows some performance measurements of typical tasks such as builds.</simpara>
-</section>
-<section xml:id="_source-mapping">
-<title>Source Mapping</title>
-<simpara>Shows source maps, i.e. the relation between N4JS source code and the generated plain JavaScript code.</simpara>
-</section>
-<section xml:id="_xpect-view">
-<title>Xpect View</title>
-<simpara>Shows result of an Xpext run, may be used to submit bug reports.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_navigation">
-<title>Navigation</title>
-<simpara>In this chapter we describe specific views and features to allow for easy navigation.</simpara>
-<section xml:id="sec:Outline_Navigation" role="language-n4js">
-<title>Outline</title>
-<simpara>In general, a outline view and a quick outline are supported. Both outlines work similar, which is why both are specified together. The outline of an N4JS file is a tree which should show the following structure: <anchor xml:id="sec:N4JS_Outline" xreflabel="[sec:N4JS_Outline]"/></simpara>
-<itemizedlist>
-<listitem>
-<simpara>Top-level defined classes, interfaces, roles, enums, functions and exported variables. For all these different types, icons are to be used (similar to JDT). Beside the name, type variables should be shown as well, if defined.</simpara>
-</listitem>
-<listitem>
-<simpara>Members of classifiers are to be shown in the classifier branch. All members (fields, methods, field accessors) are to be shown, with appropriate icons indicating the type (field/member), static flag, access modifier, abstract flag. The icons should look similar to JDT.</simpara>
-</listitem>
-<listitem>
-<simpara>an import declaration should have a node in the outline view, if multiple elements are imported these should represented as child nodes of that import declaration node. If the import uses aliases the original name and the alias name should appear in the outline node text.</simpara>
-</listitem>
-<listitem>
-<simpara>for a non exported function declaration no outline node should be created</simpara>
-</listitem>
-<listitem>
-<simpara>for a non exported variable declaration no outline node should be created</simpara>
-</listitem>
-<listitem>
-<simpara>for a exported variable statement there should be a node in the outline, if this statement contains only one variable declaration the node represents this declaration. For multiple variable declarations in the statement the statement node just is a comma separated list of the variable names and for each variable there is child node</simpara>
-</listitem>
-<listitem>
-<simpara>for fields, functions, methods, getters and variables their declared (return) type should be shown (by adding : typeName after the element name). If the type is inferred then the type name should be presented in a different color</simpara>
-</listitem>
-<listitem>
-<simpara>for functions, methods and setters each formal parameter should be represented by its declared or inferred type (when inferred than with different color)</simpara>
-</listitem>
-<listitem>
-<simpara>constructors are represented by the method icon and a decorator in the top right corner</simpara>
-</listitem>
-<listitem>
-<simpara>enumeration literals are represented with the same decoration as static final fields</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The top-level elements must be sortable either by order in the file (default) or alphabetically.</simpara>
-<section xml:id="_quick-outline">
-<title>Quick Outline</title>
-<simpara>The quick outline supports two modes. The modes are iteratively selected by pressing <keycombo><keycap>CMD/CTRL</keycap><keycap>O</keycap></keycombo>.</simpara>
-<variablelist>
-<varlistentry>
-<term>owned</term>
-<listitem>
-<simpara>This is the default mode, only members directly owned by the type are shown</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>inherited</term>
-<listitem>
-<simpara>In this mode, the owned members are shown including inherited, consumed, or polyfilled members. The origin is also shown and a different color is used to highlight the special status of these members. For usability reasons (limiting the number of filters), inherited, consumed and polyfilled members are treated similarly.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_normal-outline">
-<title>Normal Outline</title>
-<simpara>In the normal outline view, toggles are used for the same purpose. Visualisations are similar to the quick outline view.</simpara>
-<variablelist>
-<varlistentry>
-<term>inherited</term>
-<listitem>
-<simpara>By default, only owned members of a type are shown. If the "inherited" toggle is active, inherited, consumed, or polyfilled members as well. For usability reasons (limiting the number of filters), inherited, consumed, and polyfilled members are treated similarly.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara></simpara>
-<sidebar>
-<simpara><link xl:href="https://github.com/eclipse/n4js/issues/99"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #99</link></simpara>
-</sidebar>
-<variablelist>
-<varlistentry>
-<term>sorting</term>
-<listitem>
-<simpara>By default, all elements are sorted in the order of their appearance in the source code. If alphabetic sorting is enabled, they are sorted alphabetically.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<todo>
-<simpara>Potential improvements:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>show decorator when a member overrides and member from a super class / super interface or role</simpara>
-</listitem>
-<listitem>
-<simpara>show object literals and their members in the outline view (just filter <literal>eAllContents</literal> of an element that already has a node in outline view for object literals)</simpara>
-</listitem>
-<listitem>
-<simpara>show function expression in the outline view (just filter <literal>eAllContents</literal> of an element that already has a node in outline view for function expressions)</simpara>
-</listitem>
-</itemizedlist>
-</todo>
-</section>
-</section>
-<section xml:id="_navigation-commands">
-<title>Navigation Commands</title>
-<section xml:id="sec:Navigate_to_Declaration">
-<title>Navigate to Declaration</title>
-<simpara>It is possible to Command-click on almost every reference and jump to its declaration.</simpara>
-</section>
-<section xml:id="sec:find_by_references">
-<title>Find by References</title>
-<simpara>For each referenceable element in an open N4JS file you can click your mouse and invoke the context menu to select <literal>Find references</literal>. Then in the Eclipse search view all found references are displayed as tree: each match is structured by resource path and coarse grained element in the resource (like a method). If there are multiple matches within a method only the first match is linked but in its display string the total match count is shown in brackets.</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>find by references shows the result as tree in the Eclipse search view with having elements that are members or have defined type displayed as nodes</simpara>
-</listitem>
-<listitem>
-<simpara>every found reference is displayed under its nearest parent that is a member or has a defined type</simpara>
-</listitem>
-<listitem>
-<simpara>if there a multiple found references in a node only the first one is displayed (and linked) + the number of all total matches is shown as part of the display string (like in JDT)</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Open_Type_Declaration">
-<title>Open Type Declaration</title>
-<simpara>One can quickly browse the workbench for available types. The declaration of the types can be opened in editor from this dialog. The N4JS type search dialog can be raised with the <keycap>Cmd</keycap> + <keycap>Shift</keycap> + <keycap>T</keycap> key binding (<keycap>Ctrl</keycap> + <keycap>Shift</keycap> + <keycap>T</keycap> on Windows and Linux systems).</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Enter <emphasis role="strong">exact type name</emphasis>, prefix name or a camel case pattern to run a query against the types. The following rules and patterns are supported.</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis role="strong">Wildcards</emphasis>: <literal>?</literal> for any character and <literal>*</literal> for any string.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Camel case</emphasis>: <literal>DM</literal> will return with all types that contains <literal>D</literal> and <literal>M</literal> with the given order such as <literal>DataMap</literal> and <literal>DataMapEntry</literal> but not <literal>ImmutableDataMap</literal>.</simpara>
-<simpara><literal>AcBuGr</literal> will return with all types that contain <literal>Ac</literal>, <literal>Bu</literal> and <literal>Gr</literal> with the given order such as <literal>ActionButtonGroup</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Highlighting</emphasis>: The matching types names are highlighted according to the matching parts.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Decorator</emphasis> for duplicate type names: The internally used fully qualified name of the type will be appended to the type name automatically, so one can easily distinguish between types even there are type name collision.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Opening types in editor</emphasis>: Type declarations can be opened in the editor in the following ways: after entering the type name prefix or pattern to the filter text one can navigate among the filtered items with the up and/or down arrow keys. Simply hitting return on the keyboard or clicking on the ’OK’ button the currently selected declaration of the selected type will be opened in the editor. For opening multiple type declarations one can use the <keycap>Shift</keycap> modifier to select more than one element. Single type can be opened with double clicking on it in the dialog.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">History</emphasis>: Once a type is being opened then it will be available among the recently opened type in the type search dialog. These items will show up in the upper part of the list in the dialog.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-<section xml:id="sec:Working_Sets" role="language-bash">
-<title>Working Sets</title>
-<simpara>Working sets are used to logically group resources, projects in the Project Explorer (navigator) and in the UI in general. Although a couple of projects can be easily handled and shown without any sophisticated working set support in the navigator, larger code sources consisting of multiple projects could cause some trouble when one has to maintain them. Indeed one could use multiple workspaces and could switch between them or can simply manually open-close relevant projects, but this gets cumbersome too.</simpara>
-<simpara>This section describes the general design of the N4JS specific working set support and also introduces a couple of use cases while enumerating the constraints.</simpara>
-<section xml:id="sec:Working_Set_Managers">
-<title>Working Set Managers</title>
-<simpara>Just like the JDT (<literal>org.eclipse.jdt.internal.ui.workingsets.WorkingSetModel</literal>) based working set support, the N4JS IDE based approach is also aware of the <literal>org.eclipse.ui.IWorkingSet</literal> and the <literal>org.eclipse.ui.IWorkingSetManager</literal> APIs but besides simply using them it comes with its own implementation and adapts it to the default Eclipse based one, furthermore it also comes with an Eclipse extension point based mechanism to support various working set managers at the same time to provide even better user experience and a more convenient way of working set management.</simpara>
-<simpara>A working set manager can be contributed to the IDE via the <literal>org.eclipse.n4js.ui.workingSetManager</literal> extension point, then the implementation class must implement the <literal>org.eclipse.n4js.ui.workingsets.WorkingSetManager</literal> interface but it is highly recommended to rather extend the <literal>org.eclipse.n4js.ui.workingsets.WorkingSetManagerImpl</literal> class. Guice based dependency injection should also be considered when implementing the custom working set manager. It means that each custom working set manager implementation must have a public <emphasis>no-args</emphasis> constructor. This <emphasis>no-args</emphasis> constructor will be invoked when creating the instances via <literal>IConfigurationElement#createExecutableExtension(String)</literal> method. Then the members, if any will be injected by the working set manager broker. Below <literal>plugin.xml</literal> snippet describes how to contribute a custom working set manager to the IDE.</simpara>
-<programlisting language="xml" linenumbering="unnumbered"> <extension
- point="org.eclipse.n4js.ui.workingSetManager">
- <manager
- class="some.package.name.MyExecutableExtensionFactory:some.package.name.MyWorkingSetManager">
- </manager>
- </extension></programlisting>
-<simpara>By default the N4JS IDE comes with five different built-in working set managers. These are the followings:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Manual Association Working Set Manager,</simpara>
-</listitem>
-<listitem>
-<simpara>Project Name Filter Working Set Manager,</simpara>
-</listitem>
-<listitem>
-<simpara>Git Repository Working Set Manager,</simpara>
-</listitem>
-<listitem>
-<simpara>Project Location Working Set Manager and</simpara>
-</listitem>
-<listitem>
-<simpara>N4JS Project Type Working Set Manager.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The benefits and the details of each built-in working set managers will be discussed in later sections but first we have to distinguish between three conceptually different working set manager approaches.</simpara>
-<simpara>First off, IDE supports fully static working set managers. Fully static working set managers might manage any arbitrary number of working sets, and each working set might be associated with any number of Eclipse projects. That means, user might create, edit and remove working sets and manually associate projects with individual working sets. One project might belong to multiple working sets. There is a dedicated working set, <emphasis>Other Projects</emphasis>, that cannot be renamed and/or deleted. When no user defined working sets are available this dedicated working set will be still available. IDE comes with one single fully static working set manager: <emphasis>Manual Association Working Set Manager</emphasis>.</simpara>
-<simpara>The second kind of working set manager is the semi-dynamic one. That means, user can create, modify and delete working sets, but the associations between the projects and the working sets are automatic. This means, the user might define a working set - project association rule, and the projects will be automatically associated with the working sets. Just like in the above kind, one project might belong to multiple working sets and here as well, there is a dedicated working set manager, that cannot be modified: <emphasis>Other Projects</emphasis>. IDE comes with one semi-dynamic working set manager. That is the <emphasis>Project Name Filter Working Set Manager</emphasis>. User might define a project name filter rule with a regular expression, and each project which name matches a pattern will be associated with the working set. If a project does not comply to any working set manager rule, then it will belong to the <emphasis>Other Projects</emphasis> working set.</simpara>
-<simpara>The third kind of working set manager is the fully-dynamic working set manager. Both the working sets and the project associations are done by some implementation specific rules. Such as Git repository provider based, or project location based approaches. These working set managers have the dedicated <emphasis>Other Projects</emphasis> working set that is used as a fallback working set. For instance, if the <emphasis>Git Repository Working Set Manager</emphasis> is the active one, all projects that are shared with Git will belong to the corresponding working set manager but if a project is not yet a shared project, then it will belong to the dedicated fallback working set. As always that working set manager cannot be deleted and/or modified.</simpara>
-</section>
-<section xml:id="sec:Working_Set_Constraints">
-<title>Working Set Constraints</title>
-<simpara>This section enumerates a set of constraints that have to considered by both end users and implementors:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Working set manager identifier must be unique.</simpara>
-</listitem>
-<listitem>
-<simpara>The identifier of the working set manager must be unique per container working set managers.</simpara>
-</listitem>
-<listitem>
-<simpara>Each working set must have a working set with <emphasis>Other Projects</emphasis> unique ID and name.</simpara>
-</listitem>
-<listitem>
-<simpara>Working sets with <emphasis>Other Projects</emphasis> unique ID must not be editable nor deletable.</simpara>
-</listitem>
-<listitem>
-<simpara>At least one working set should be visible (not hidden) per working set managers.</simpara>
-</listitem>
-<listitem>
-<simpara>Working set managers are activated when the <emphasis>Working Sets</emphasis> are configured as <emphasis>Top Level Elements</emphasis> in the <emphasis>Project Explorer</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara>Working set order can be specified and customized by the user if it is not specified yet, then a case sensitive ordering based on the working set names should be applied.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Manual_Association_Working_Set_Manager_UI_Features">
-<title>Manual Association Working Set Manager - UI Features</title>
-<simpara>This section describes the working set manager by introducing the UI capabilities as well.</simpara>
-<simpara>This working set manager is a fully static working set manager and activated and used as the default one when the working set manager support is turned on in the IDE. With this working set manager one can create a new working set by simply defining a unique name for the working set and associating any number of workspace project to the working set. Furthermore existing working sets can be modified and deleted but the <emphasis>Other Projects</emphasis> working set. The working set support can be turned on in the <emphasis>Project Explorer</emphasis> view. Via the view menu one has to select <emphasis>Top Level Elements</emphasis> <emphasis>></emphasis> <emphasis>Working Sets</emphasis> menu item.</simpara>
-<figure role="center">
-<title>Activate Working Set Managers</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/activate_working_set_managers.png" width="50%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Activate_Working_Set_Managers</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>After the working set manager mode activation, a new toolbar contribution item become visible and user can select among the available working set managers.</simpara>
-<figure role="center">
-<title>Select Working Set Manager</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/select_working_set_manager_01.png" width="50%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Select_Working_Set_Manager</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>As the below picture depicts the available working set managers are listed and the currently active manager is marked with a check. In our case that is the <emphasis>Manual Association Working Set Manager</emphasis>.</simpara>
-<figure role="center">
-<title>Activate Working Set Manager</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/select_working_set_manager_02.png" width="25%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Activate_Working_Set_Manager</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Once the the <emphasis>Configure Manual Association…​</emphasis> menu item is selected, the working set manager configuration dialog pops up. By clicking on the <emphasis>New…​</emphasis> button in the configuration dialog, a new working set wizard will be invoked and the manual working set - project association can be configured.</simpara>
-<figure role="center">
-<title>Configure Working Sets</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/configure_working_sets_01.png" width="25%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Configure_Working_Sets</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>In the wizard after specifying the desired unique name of the working set an arbitrary number of workspace projects can be associated with the working set. It is important to note, that a project can be associated with more than one working sets. If a project is not associated with any working sets then it will be automatically linked to the fallback <emphasis>Other Projects</emphasis> working set.</simpara>
-<figure role="center">
-<title>Working Set - Projects Association</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/working_set_project_association.png" width="50%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Configure_Working_Set_Project_Association</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Once all the changes made are confirmed and the configuration dialog is closed via the <emphasis>OK</emphasis> button, the <emphasis>Project Explorer</emphasis> will be refreshed and will reflect the working set changes.</simpara>
-<figure role="center">
-<title>Custom Working Sets In Project Explorer</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/working_sets_in_navigator.png" width="25%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Custom_Working_Sets_In_Project_Explorer</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The order of the working sets can be configured and customized in the working set manager configuration dialog, or just simply reordering it from the navigator itself by drag and dropping the available working set managers.</simpara>
-<figure role="center">
-<title>Re-ordering Working Sets In Project Explorer</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/working_set_reorder.png" width="25%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Re_Ordering_Working_Sets_In_Project_Explorer</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Besides changing the order of the working sets, working sets can be hidden from the navigator. Just like the ordering, this can be changed from the working set configuration dialog, or by simply selecting working sets in the navigator and hiding them via <emphasis>Hide Selected Working Set</emphasis> menu item. Important to note, at least one working set should be visible in the navigator, so if all the working sets are selected in the navigator, then the menu item will be disabled. Same behavior in the working set customization dialog, if all items are unchecked, then the <emphasis>OK</emphasis> button is disabled in the dialog.</simpara>
-<figure role="center">
-<title>Hide Working Sets In Project Explorer</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/working_set_hide.png" width="25%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Hide_Working_Sets_In_Project_Explorer</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Once at least one working set is hidden from the UI, then a new toolbar contribution become visible in the <emphasis>Project Explorer</emphasis>. This UI contribution provides a quick, convenient way to show a specific or all hidden working sets in the navigator. It is worth to note, if a project is automatically associated with the <emphasis>Other Projects</emphasis> working set (because it does not belong to any working sets due to the lack of manual association) it will be not shown in the navigator if the <emphasis>Other Projects</emphasis> working set is hidden. Once all working sets are visible, indeed the <emphasis>Show Hidden Working Sets</emphasis> toolbar contribution become invisible.</simpara>
-<figure role="center">
-<title>Show Hidden Working Sets In Project Explorer</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_navigation/fig/working_set_show.png" width="25%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>Show_Hidden_Working_Sets_In_Project_Explorer</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Besides the above described generic working set UI support, projects can be associated with working sets by simply drag and dropping them from one working set into another. Note, this is only supported for the <emphasis>Manual Association Working Set Manager</emphasis>.</simpara>
-</section>
-<section xml:id="sec:Project_Name_Filter_Working_Set_Manager">
-<title>Project Name Filter Working Set Manager</title>
-<simpara>As mentioned earlier, this working set is a semi-dynamic working set. The working sets can be created, edited and deleted by the user by simply specifying project name filter pattern as valid regular expressions but the project association itself is fully automatic. If the name of a project does not match with any project name filter rule, then the project will be associated with the <emphasis>Other Projects</emphasis> working set. Although reordering the working sets from the navigator by simple drag and dropping them is supported, project association is disabled.</simpara>
-</section>
-<section xml:id="sec:Git_Repository_Working_Set_Manager">
-<title>Git Repository Working Set Manager</title>
-<simpara>This working set is a fully-dynamic working set. Projects will be associated by the Git providers. It means, if a project is imported from a pre-configured local Git repository, then the project will be associated with the working set linked with the Git repository. The subset of the available working sets is become automatically updated once the Git repository preferences changed by the user. These preferences can be changed on the <emphasis>Git</emphasis> perspective in the <emphasis>Git Repositories</emphasis> view by simple adding or hiding/removing a repository from the view.</simpara>
-</section>
-<section xml:id="sec:Project_Location_Working_Set_Manager">
-<title>Project Location Working Set Manager</title>
-<simpara>This fully-dynamic working set manager calculates the subset of available working sets based on the parent folder of the projects. The benefit of this working set manager is to support the convention recommended by the maven/Git folder structuring. The following constraints are applied when associating the projects with the available working sets:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If a project is located in the root of the Eclipse workspace, then it will be associated with <emphasis>Other Projects</emphasis> working set.</simpara>
-</listitem>
-<listitem>
-<simpara>If a project is nested somewhere in the Eclipse workspace, then it will be associated with a working set that has the same name as the parent folder of the project. Let assume the Eclipse workspace root points to <literal>/eclipse/root</literal> and there is a project <literal>P1</literal> nested in the workspace root at <literal>/eclipse/root/path/to/nested/location/P1</literal>, then the associated working set will be <literal>location</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>If a project is not contained in the workspace, but has a Git provider that is configured in IDE, and the project root is the local Git repository root, then the associated working set name will be the name of the Git repository. For example, if we have Eclipse workspace root pointing to <literal>/eclipse/root</literal> location and a <literal>P2</literal> project located <literal>/some/path/to/git/P2</literal> but this location is the location of a registered Git repository, then the name of the associated working set will be neither <literal>Other Projects</literal> not <literal>git</literal> but <literal>P2</literal> since that is known Git local repository root.</simpara>
-</listitem>
-<listitem>
-<simpara>If project <literal>P3</literal> is not contained in the Eclipse workspace but contained in a known local Git repository just like above, but the project root is not the local Git repository root, then the name of the parent folder will be considered as the name of the associated working set. This rule is a hybrid alternative of the second and the third constraints, hence for instance if the project is under <literal>/some/path/to/git/repositoryName/plugins/P3</literal> and <literal>repositoryName</literal> is local git repository, then the name of the associated working set will be <literal>plugins</literal> and not <literal>repositoryName</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Else the associated working set will be the <emphasis>Other Projects</emphasis> fallback working set.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:N4JS_Project_Type_Working_Set_Manager">
-<title>N4JS Project Type Working Set Manager</title>
-<simpara>This is working set manager is a N4JS specific fully-dynamic working set manager. The working sets will be calculated based on the instances defined by the <literal>org.eclipse.n4js.n4mf.ProjectType</literal> type. Each accessible N4JS project will be associated to a working set based on the project type. A workspace project will be associated with the <emphasis>Other Projects</emphasis> fallback working set if any of the followings are true to the project:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The project is not accessible. (It does not exist or is not opened.)</simpara>
-</listitem>
-<listitem>
-<simpara>The project does not configured with <emphasis>Xtext</emphasis> nature.</simpara>
-</listitem>
-<listitem>
-<simpara>The project does not have an <emphasis>Xtext</emphasis> builder command ID.</simpara>
-</listitem>
-<listitem>
-<simpara>The project does not have a valid N4 manifest file.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_assistance">
-<title>Assistance</title>
-<simpara>In this chapter we describe all kind of tools assisting the user when writing code, i.e. content assist, quickfixes, quick assists, etc.</simpara>
-<warning>
-<simpara>Not all features are yet implemented!</simpara>
-</warning>
-<section xml:id="sec:Content_Assist" role="language-n4js">
-<title>Content Assist</title>
-<simpara>Content assist may change the document at various places at once. In those cases, it is important to prevent flickering in the editor. The FQNImporter provides a blue print how to adjust line numbers properly and scroll the viewport of the current editor to minimize flickering in the UI.</simpara>
-<simpara>Completions not listed here as they are provided by template proposals:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Classifier declaration template proposal</simpara>
-</listitem>
-<listitem>
-<simpara>Function declaration template proposal</simpara>
-</listitem>
-<listitem>
-<simpara>Getter/Setter pair template proposal</simpara>
-</listitem>
-</orderedlist>
-<section xml:id="sec:Complete_Keywords">
-<title>Complete Keywords</title>
-<simpara>Complete keyword which are syntactically correct at a given location. Do not suggest completions which would lead to wrong code.</simpara>
-<simpara>Keywords that contain only a single character are not proposed since they would pollute the proposal window and don’t offer added value.</simpara>
-<simpara>Special attention has to be given to operators. Since they are modelled in the grammar and not as cross references, their validaty is purely syntactically. That is, there is no generic facility in Xtext, that allows to filter unapplicable operators as there is for cross references.</simpara>
-</section>
-<section xml:id="sec:Complete_Annotations">
-<title>Complete Annotations</title>
-<simpara>Annotations can be proposed depending on the following elements or the context.</simpara>
-</section>
-<section xml:id="sec:Complete_Identifier_Reference">
-<title>Complete Identifier Reference</title>
-<simpara>References to identifiers can be automatically completed. This is even true if the declaration is not imported yet, as the import may be automatically added as well.</simpara>
-<simpara>The IDE supports auto-completion of an identifier referencing to a declaration.</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Complete type references.</simpara>
-</listitem>
-<listitem>
-<simpara>Complete function references.</simpara>
-</listitem>
-<listitem>
-<simpara>Complete variable references.</simpara>
-</listitem>
-<listitem>
-<simpara>Complete parameter references.</simpara>
-</listitem>
-<listitem>
-<simpara>If necessary, imports are added automatically to complete reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>r</mi></math> to declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math>.</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>-</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>⇔</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>r</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>D</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>D</mi><mo>∈</mo><mi>r</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>⊕</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∃</mo><mstyle mathvariant="monospace"><mtext>NamedImportSpecifier</mtext></mstyle><mi>N</mi><mi>I</mi><mi>S</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>W</mi><mi>I</mi><mi>S</mi><mo>.</mo><mi>i</mi><mi>m</mi><mi>p</mi><mi>o</mi><mi>r</mi><mi>t</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mo>.</mo><mi>i</mi><mi>m</mi><mi>p</mi><mi>o</mi><mi>r</mi><mi>t</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>=</mo><mi>D</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∨</mo><mo>∃</mo><mstyle mathvariant="monospace"><mtext>WildcardImportSpecifier</mtext></mstyle><mi>W</mi><mi>I</mi><mi>S</mi><mi>:</mi></math></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Description</term>
-<listitem>
-<simpara>There might be multiple declarations <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math> in project (or in dependent projects) with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>r</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math>. If the declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math> is not local, then a named import may be created by the content assist:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>If the declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math> is local, no import is created</simpara>
-</listitem>
-<listitem>
-<simpara>If an import enabling access to the declaration already exists, no other import is created.</simpara>
-</listitem>
-<listitem>
-<simpara>If an alias already exists, the alias name is used, even if the prefix was different when the content assist was activated.</simpara>
-</listitem>
-<listitem>
-<simpara>If the import would conflict with an existing member, an alias is proposed along with the import. Linked editing helps to choose a proper alias.</simpara>
-</listitem>
-<listitem>
-<simpara>All imports from a single module are done within a single import declaration. The exception to this rule are wildcard imports that provide a simple name which is currently unused. In that case, a new import may be necessary to disambiguate the wildcard.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-<listitem>
-<simpara>If the identifier reference refers to a function (or method), an opening and a closing parenthesis are appended and
-the cursor is positioned between these two parentheses.</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Complete_Member_Overrides">
-<title>Complete Member Overrides</title>
-<simpara>A prefix of an inherited member can be used to autocomplete that to a complete declaration.
-This is in particular true for methods.</simpara>
-</section>
-<section xml:id="sec:Constructor_Completion">
-<title>Constructor Completion</title>
-<simpara>Constructor Completion Based on the declared fields and super constructor, constructor methods can be completed.</simpara>
-</section>
-<section xml:id="sec:Complete_Function_Expression">
-<title>Complete Function Expression with Known Type</title>
-<simpara>If a function expression is used as an argument or assigned to a typed variable, the signature of the function can be derived from the type. This can be used to complete a function expression.</simpara>
-</section>
-<section xml:id="sec:Complete_Variable_and_Parameter_Names">
-<title>Complete Variable and Parameter Names</title>
-<simpara>Variable and parameter names can be completed based on the type. Camel case detection is used to propose different variations.</simpara>
-<simpara>Completion of variables references see <link linkend="sec:Complete_Identifier_Reference">Complete Identifier Reference</link>.</simpara>
-</section>
-</section>
-<section xml:id="sec:Quick_Fixes" role="language-n4js">
-<title>Quick Fixes</title>
-<simpara>Quick fixes try to solve issues, i.e. errors or warnings, automatically. This is done by rewriting code, either at the location of the issue or at referenced locations.</simpara>
-<simpara>In all cases, a quick fix must only be suggested if the following preconditions are fulfilled:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>All locations at which modifications have to be done must be writeable.</simpara>
-</listitem>
-<listitem>
-<simpara>If bindings are involved, e.g., names are to be changed, all previous bindings must remain similar. This might be more complicated as it seems!</simpara>
-</listitem>
-</orderedlist>
-<section xml:id="sec:N4JS_Issue_Properties">
-<title>N4JS Issue User data</title>
-<simpara>As some quick fixes need more information to decide upfront which strategy to use, some issues provide additional data. These properties are defined in the file <literal>IssueUserDataKeys.java</literal> in the <literal>org.eclipse.n4js.validation</literal> package. They can for example be accessed by passing the according key to the <literal>getUserData</literal> method of an <literal>N4JSIssue</literal> instance. They are also available as array based Xtext Issue user data.<?asciidoc-br?></simpara>
-<simpara>All available user data keys are described for each Issue code in <link linkend="sec:N4JS_Issue_Fixes">N4JS Issue Fixes</link>.</simpara>
-</section>
-<section xml:id="sec:N4JS_Issue_Fixes">
-<title>N4JS Issue Fixes</title>
-<simpara>The principle idea is to provide a quick fix for every issue, if it is possible to automatically solve it.</simpara>
-<section xml:id="sec:Linking_Issues">
-<title>Linking Issues</title>
-<simpara>Linking issues are special in that they are created by the standard Xtext linker and use all the same built-in issue code <literal>Diagnostic.LINKING_DIAGNOSTIC</literal>. Therefore, we cannot refer to these issues using one of our custom N4JS issue codes.</simpara>
-<variablelist>
-<varlistentry>
-<term>Diagnostic.LINKING_DIAGNOSTIC</term>
-<listitem>
-<simpara><literal>Couldn’t resolve reference to <emphasis>n</emphasis></literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Add missing import declaration for unresolved name <emphasis>n</emphasis>.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Precondition</simpara>
-</entry>
-<entry>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>An exported identifiable element <emphasis>e</emphasis> with name <emphasis>n</emphasis> exists in another module <emphasis>m</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis>e</emphasis> is visible from the given location.</simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Label</simpara>
-</entry>
-<entry>
-<simpara><literal>Import <emphasis>n</emphasis> - <emphasis>m</emphasis></literal></simpara>
-<variablelist>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara>An import declaration was added such that name <emphasis>n</emphasis> is now resolvable at the given location and bound to <emphasis>e</emphasis>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Description</term>
-<listitem>
-<simpara>Some important notes:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>A</literal> separate quick fix is proposed for each candidate element instead of having a single generic quick fix for adding imports and showing a dialog later (for example, create two quick fixes “Import class <literal>X</literal> from module M1" and “Import interface <literal>X</literal> from module M2" instead of a single quick fix “Add import for name X").<?asciidoc-br?>
-This is unusual for quick fixes, because it means significant work has to be done upfront when creating the quick fix / modification proposals, which raises performance concerns. However,</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>the JDT handles this the same way and</simpara>
-</listitem>
-<listitem>
-<simpara>this brings the implementation closer to content assist allowing more reuse, therefore this decision was taken.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>For consistency, matching of lower/upper/camel case is to be handled as in code completion during content assist. The same applies to display string formatting, esp. name formatting and coloring of element <emphasis>e</emphasis> and module <emphasis>m</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara>Note that here we can make more assumptions than during import as part of content assist. For example, we know that the element is not imported yet (otherwise there would not be an error) and there won’t be a need for an alias and linked editing.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Import_Issues">
-<title>Import Issues</title>
-
-</section>
-<section xml:id="sec:Visibility_Issues">
-<title>Visibility Issues</title>
-<variablelist>
-<varlistentry>
-<term>VIS_ILLEGAL_MEMBER_ACCESS</term>
-<listitem>
-<simpara><literal>The <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi></math> is not visible.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Change access modifier to protected/public or remove <literal>@Internal</literal> annotation.</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>The file containing the declaration of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi></math> is modifiable</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara>The access modifier has been changed so that <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi></math> is visible at issue location.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>User Data</term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara><emphasis role="strong">ACCESS_SUGGESTION</emphasis> The most restrictive modifier making the member visible.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">DECLARATION_OBJECT_URI</emphasis> The EObject URI of the member declaration</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>This table shows the access modifier changes to perform to fix the visibility issue while maintaining the strongest access restrictions possible.</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="7">
-<colspec colname="col_1" colwidth="14.2857*"/>
-<colspec colname="col_2" colwidth="14.2857*"/>
-<colspec colname="col_3" colwidth="14.2857*"/>
-<colspec colname="col_4" colwidth="14.2857*"/>
-<colspec colname="col_5" colwidth="14.2857*"/>
-<colspec colname="col_6" colwidth="14.2857*"/>
-<colspec colname="col_7" colwidth="14.2858*"/>
-<tbody>
-<row>
-<entry align="center" valign="top" morerows="1"><simpara><literal>Access Modifier</literal></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_7"><simpara><literal>Accessible From</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>Inside Module</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Inside Project</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Vendor Subtypes</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Vendor Projects</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Other Subtypes</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Everywhere</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>private</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>project</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>protected@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>protected</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>project</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>protected@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>protected</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>protected@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>protected</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>protected</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>-</literal></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Member access modifier changes for quick fixes</simpara>
-<variablelist>
-<varlistentry>
-<term>VIS_ILLEGAL_FUN_ACCESS</term>
-<listitem>
-<simpara><literal>The function <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> is not visible.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Change access modifier to protected/public or remove <literal>@Internal</literal> annotation.</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara>The access modifier has been changed so that <emphasis>f</emphasis> is visible at issue location.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>User Data</term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara><emphasis role="strong">ACCESS_SUGGESTION</emphasis> The most restrictive modifier making the function visible.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">DECLARATION_OBJECT_URI</emphasis> The EObject URI of the function declaration</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>VIS_ILLEGAL_TYPE_ACCESS</term>
-<listitem>
-<simpara><literal>The type <emphasis>T</emphasis> is not visible.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Change access modifier to protected/public or remove <literal>@Internal</literal> annotation.</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara>The access modifier has been changed so that <emphasis>T</emphasis> is visible at issue location.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>User Data</term>
-<listitem>
-<simpara>see VIS_ILLEGAL_FUN_ACCESS</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>VIS_ILLEGAL_VARIABLE_ACCESS</term>
-<listitem>
-<simpara><literal>The variable <emphasis>v</emphasis> is not visible.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Change access modifier to protected/public or remove <literal>@Internal</literal> annotation.</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>Module containing <emphasis>v</emphasis> is writeable.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara>The access modifier has been changed so that <emphasis>v</emphasis> is visible at issue location.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>User Data</term>
-<listitem>
-<simpara>see VIS_ILLEGAL_FUN_ACCESS</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>For type, variable and function visibility issues the following changes have to be made to solve the visibility issue:</simpara>
-<table xml:id="tab:typeAccessControl" frame="all" rowsep="1" colsep="1">
-<title>Type,function and variable access modifier changes for quick fixes</title>
-<tgroup cols="5">
-<colspec colname="col_1" colwidth="20*"/>
-<colspec colname="col_2" colwidth="20*"/>
-<colspec colname="col_3" colwidth="20*"/>
-<colspec colname="col_4" colwidth="20*"/>
-<colspec colname="col_5" colwidth="20*"/>
-<tbody>
-<row>
-<entry align="center" valign="top" morerows="1"><simpara><emphasis role="strong">Access Modifier</emphasis></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_5"><simpara><emphasis role="strong">Accessible From</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Module</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Project</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Vendor</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">World</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>private</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export project</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export public@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>project</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export project</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export public@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>export project</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export public@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>export public@Internal</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export public</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>export public</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>export public</literal></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-</section>
-<section xml:id="sec:Classifier_Issues">
-<title>Classifier Issues</title>
-<variablelist>
-<varlistentry>
-<term>CLF_EXTEND_FINAL</term>
-<listitem>
-<simpara><literal>Cannot extend final class <emphasis>C</emphasis>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Remove <literal>@Final</literal> annotation in class <emphasis>C</emphasis></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><mi>C</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_OBSERVABLE_MISSING</term>
-<listitem>
-<simpara><literal>Class <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> extends observable class <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> and must therefore be annotated with @Observable.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Add <literal>@Obervable</literal> annotation in class <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0.</mn></msub><mi>o</mi><mi>b</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>v</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_OVERRIDE_ANNOTATION</term>
-<listitem>
-<simpara><literal>The <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> overriding <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> must be annotated with @Override.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Add <literal>@Override</literal> annotation to <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Label</term>
-<listitem>
-<simpara><literal>Add @Override</literal></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0.</mn></msub><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_OVERRIDE_FINAL</term>
-<listitem>
-<simpara><literal>The <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> cannot override final <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Remove <literal>@Final</literal> annotation in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><msub><mi>e</mi><mn>1.</mn></msub><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_OVERRIDE_VISIBILITY</term>
-<listitem>
-<simpara><literal>The <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> cannot reduce the visibility of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Set access modifier of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> to access modifier of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0.</mn></msub><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mo>=</mo><msub><mi>e</mi><mn>1.</mn></msub><mi>a</mi><mi>c</mi><mi>c</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_OVERRIDE_NON_EXISTENT</term>
-<listitem>
-<simpara><literal>The <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> must override or implement a <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> from a super class, consumed role or implemented interface.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Remove <literal>@Override</literal> annotation in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Label</term>
-<listitem>
-<simpara><literal>Remove @Override</literal></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><msub><mi>e</mi><mn>1.</mn></msub><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_REDEFINED_TYPE_NOT_SAME_TYPE</term>
-<listitem>
-<simpara><literal>Type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> must equal type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>2</mn></msub></math>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Set declared type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> to declared type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>2</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>τ</mi><msub><mi>e</mi><mn>0</mn></msub><mo>=</mo><msub><mi>e</mi><mn>2</mn></msub></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_REDEFINED_MEMBER_TYPE_INVALID</term>
-<listitem>
-<simpara><literal>Type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> does not conform to <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>2</mn></msub></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math>: <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>3</mn></msub></math>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Set declared type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> to declared type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>τ</mi><msub><mi>e</mi><mn>0</mn></msub><mo>=</mo><msub><mi>e</mi><mn>1</mn></msub></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_REDEFINED_METHOD_TYPE_CONFLICT</term>
-<listitem>
-<simpara><literal>Signature of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> does not conform to <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>2</mn></msub></math>: <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>3</mn></msub></math>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Set declared type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> to declared type of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>2</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>τ</mi><msub><mi>e</mi><mn>0</mn></msub><mo>=</mo><msub><mi>e</mi><mn>2</mn></msub></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_MISSING_IMPLEMENTATION</term>
-<listitem>
-<simpara><literal>Class <emphasis>C</emphasis> must either be defined abstract or implement <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi></math>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Declare <emphasis>C</emphasis> as abstract</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_ABSTRACT_BODY</term>
-<listitem>
-<simpara><literal>Abstract methods do not specify a body.</literal> for method <emphasis>M</emphasis></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Remove abstract annotation from method.</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><mi>M</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_ABSTRACT_MISSING</term>
-<listitem>
-<simpara><literal>The abstract <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> in class <emphasis>C</emphasis> can only be defined in an abstract class.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Declare <emphasis>C</emphasis> as abstract</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Multi appliable</term>
-<listitem>
-<simpara>false</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_MISSING_BODY</term>
-<listitem>
-<simpara><literal>The <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> has to have either a body or must be defined abstract.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Declare <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> as abstract</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1.</mn></msub><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_EXT_EXTERNAL_N4JSD</term>
-<listitem>
-<simpara><literal><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> declared as external have to be placed in a file with file extension ’n4jsd’.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Remove external annotation</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><msub><mi>e</mi><mn>0.</mn></msub><mi>e</mi><mi>x</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>n</mi><mi>a</mi><mi>l</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-<listitem>
-<simpara>Change module file extension to n4jsd</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara>module file extension is n4jsd</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>CLF_NOT_EXPORTED_NOT_PRIVATE</term>
-<listitem>
-<simpara><literal>A <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> with visibility <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>1</mn></msub></math> must be marked as exported.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Export <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math></simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>e</mi><mn>0</mn></msub></math> is exported</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="sec:Function_Issues">
-<title>Function Issues</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>FUN_BLOCK</simpara>
-</entry>
-<entry>
-<simpara><literal>Functions declarations should not be placed in blocks. Use a function expression or move the statement to the top of the outer function.</literal> with function <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Change function declaration to function expression</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd/><mtd><mo>∃</mo><mstyle mathvariant="monospace"><mtext>Variable</mtext></mstyle><mi> </mi><mi>v</mi><mo>∈</mo><mi>F</mi><mo>.</mo><mi>v</mi><mi>e</mi><mi>e</mi><mi>:</mi></mtd></mtr><mtr><mtd/><mtd><mspace width="3.0em"/><mi>v</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>F</mi></mtd></mtr><mtr><mtd/><mtd><mspace width="3.0em"/><mo>∧</mo><mi>v</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>μ</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>FunctionExpression</mtext></mstyle></mtd></mtr><mtr><mtd/><mtd><mspace width="3.0em"/><mo>∧</mo><mi>v</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>,</mo><mi>v</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi></mtd></mtr></mtable></math>
-<variablelist>
-<varlistentry>
-<term>Description</term>
-<listitem>
-<simpara>Change function declaration to function expression assigned to variable of the function name</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="sec:Syntax_Issues">
-<title>Syntax Issues</title>
-<variablelist>
-<varlistentry>
-<term>AST_STR_FUN_NOT_NESTED</term>
-<listitem>
-<simpara><literal>Functions must only be declared on script level or as part of other expressions</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Change function declaration to function expression assigned to variable of the function name</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd/><mtd><mo>∃</mo><mstyle mathvariant="monospace"><mtext>Variable</mtext></mstyle><mi> </mi><mi>v</mi><mo>∈</mo><mi>F</mi><mo>.</mo><mi>v</mi><mi>e</mi><mi>e</mi><mi>:</mi></mtd></mtr><mtr><mtd/><mtd><mspace width="3.0em"/><mi>v</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>F</mi></mtd></mtr><mtr><mtd/><mtd><mspace width="3.0em"/><mo>∧</mo><mi>v</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>μ</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>FunctionExpression</mtext></mstyle></mtd></mtr><mtr><mtd/><mtd><mspace width="3.0em"/><mo>∧</mo><mi>v</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>,</mo><mi>v</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi></mtd></mtr></mtable></math>
-<variablelist>
-<varlistentry>
-<term>SYN_MODIFIER_BAD_ORDER</term>
-<listitem>
-<simpara><literal>Modifiers should appear in this order: O </literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Rearrange access modifiers</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara>Modifiers are in order O</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Description</term>
-<listitem>
-<simpara>Reorder the access modifiers to match the N4JS compliant order.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="sec:Conversion_Issues">
-<title>Conversion Issues</title>
-
-</section>
-<section xml:id="sec:Type_Issues">
-<title>Type Issues</title>
-
-</section>
-<section xml:id="sec:Expression_Issues">
-<title>Expression Issues</title>
-<variablelist>
-<varlistentry>
-<term>EXP_WRONG_NUMBER_OF_TYPEARGS</term>
-<listitem>
-<simpara><literal>Incorrect number of type arguments for <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> <emphasis>C</emphasis>: expected <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>p</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi></math>, got <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi></math>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Remove superfluous arguments</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi><mo>></mo><mi>t</mi><mi>p</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi></math></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi><mo>=</mo><mi>t</mi><mi>p</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi></math></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Description</term>
-<listitem>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>EXP_NUM_OF_ARGS_TOO_MANY</term>
-<listitem>
-<simpara><literal>Incorrect number of arguments: expected <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mi>p</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi></math>, got <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>r</mi><mi>g</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi></math>.</literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Remove superfluous arguments</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>r</mi><mi>g</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi><mo>></mo><mi>f</mi><mi>p</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi></math></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>r</mi><mi>g</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi><mo>=</mo><mi>f</mi><mi>p</mi><mi>c</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>t</mi></math></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Description</term>
-<listitem>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>EXP_CAST_UNNECESSARY</term>
-<listitem>
-<simpara><literal>Unnecessary cast from <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math></literal></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Remove cast</simpara>
-<variablelist>
-<varlistentry>
-<term>Precondition</term>
-<listitem>
-<simpara>–</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Postcondition</term>
-<listitem>
-<simpara>cast removed</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Description</term>
-<listitem>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="sec:Super_Keyword_Issues">
-<title>Super Keyword Issues</title>
-
-</section>
-</section>
-</section>
-<section xml:id="sec:Quick_Assist">
-<title>Quick Assist</title>
-
-</section>
-<section xml:id="sec:Cleanup_Operations" role="language-n4js">
-<title>Cleanup Operations</title>
-<section xml:id="sec:Formatting">
-<title>Formatting</title>
-
-</section>
-<section xml:id="sec:Organize_Imports">
-<title>Organize Imports</title>
-<simpara>Import statements can be cleaned up or automatically inserted by invoking <literal>Organize Imports</literal>. <literal>Organize Imports</literal> is available in the context menu <literal>Source / Organise imports</literal> , in menu <literal>Source > Organize imports</literal> or by hitting <keycap>Cmd</keycap> + <keycap>Option</keycap> +<keycap>O</keycap> (Win/Linux - <keycap>Ctrl</keycap> +<keycap>Alt</keycap> +<keycap>O</keycap>).</simpara>
-<simpara>For a valid file without errors, this will result in the following actions:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Unused explicit imports will be removed.</simpara>
-</listitem>
-<listitem>
-<simpara>Unused wildcard imports will be removed.</simpara>
-</listitem>
-<listitem>
-<simpara>In each import statement the imported elements will be lexicographically sorted depending on the imported element’s name.</simpara>
-</listitem>
-<listitem>
-<simpara>All import statements will be lexicographically sorted depending on the module specifier as major and the element name as minor key.</simpara>
-</listitem>
-<listitem>
-<simpara>All import statements will be moved to the top of the file.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For a file with error-conditions of unresolved references, this will result in the automatic actions:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>All ambiguous wildcard imports will be presented in one dialog, requesting the user to resolve the ambiguity.</simpara>
-</listitem>
-<listitem>
-<simpara>Each uniquely resolvable <literal>unresolved Classifier</literal> will be added by a named import. The search scope is limited to the dependencies declared in the current project-setup.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>No action will be taken, if …​</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a classifier with name <literal>X</literal> is already imported by name from a module <literal>A</literal> and a unknown member of this classifier is marked. Even though the import of <literal>X</literal> from a different module <literal>B</literal> could remove this error, the semantic consequences could not be evaluated. The state will be left as-is.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If more then one option leads to a possible resolution the situation should be clarified using quick-fixes, e.g. if …​</simpara>
-<itemizedlist>
-<listitem>
-<simpara>more then one module provides an element, which would render a formerly unresolved reference to be valid.</simpara>
-</listitem>
-<listitem>
-<simpara>for a wildcard-imported element <literal>X</literal> there are unknown members and a different module provides an element <literal>X</literal> containing the missing members. In such a case a named import of <literal>X</literal> would be proposed, optionally using an alias.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_wizards">
-<title>Wizards</title>
-<warning>
-<simpara>Some descriptions may be outdated.</simpara>
-</warning>
-<warning>
-<simpara>All requirement sections are not linked to real issues. They were left here as an example and to complete the issues.</simpara>
-</warning>
-<section xml:id="sec:N4JS_Project_Wizard">
-<title>N4JS Project Wizard</title>
-<simpara>Wizard creates a new N4JS project.</simpara>
-<simpara>The following information is to be specified by the user:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Project Name</simpara>
-</entry>
-<entry>
-<simpara>string, name of project</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Default Location</simpara>
-</entry>
-<entry>
-<simpara>boolean, true by default</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Location</simpara>
-</entry>
-<entry>
-<simpara>string, computed default location, if user set location then default location flag must be false</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Project Type</simpara>
-</entry>
-<entry>
-<simpara>enumeration, the type of the new project</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>The following files are to be created:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Project Folder</simpara>
-</entry>
-<entry>
-<simpara>with name of project at given location</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Manifest</simpara>
-</entry>
-<entry>
-<simpara>with default project structure and name</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Source Folder</simpara>
-</entry>
-<entry>
-<simpara>default source folder (src)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Output Folder</simpara>
-</entry>
-<entry>
-<simpara>default source folder (src-gen)</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Empty_N4JS_File">
-<title>Empty N4JS File</title>
-<simpara>The following information is to be specified by the user:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Package Name</simpara>
-</entry>
-<entry>
-<simpara>dot separated name of the package, empty by default (or set to the package/folder selected in the navigator)</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Module Name</simpara>
-</entry>
-<entry>
-<simpara>string, name of the module – must be a valid module name without extension</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>The following files are to be created:</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Package Folder(s)</simpara>
-</entry>
-<entry>
-<simpara>if folders representing package structure do not exist, they are to be created</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Module File</simpara>
-</entry>
-<entry>
-<simpara>empty file with name of module and extension <literal>n4js</literal> in the appropriate package folder</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-<section xml:id="sec:Empty_JS_File">
-<title>Empty JS File</title>
-<simpara>Similar to <link linkend="sec:Empty_N4JS_File">Empty N4JS File</link> but with the file extension <literal>js</literal>.</simpara>
-<section xml:id="sec:N4JS_Class_File_Wizard">
-<title>N4JS Class Wizard</title>
-<simpara>It is recommended to define a single classifier in a file, the name of the classifier should have the same name as the file. Based on that assumption, file wizards are provided for N4JS classes, interfaces and enumerations.</simpara>
-<informalfigure role="center">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/06_wizards/fig/newclasswizard.png" width="60%" scalefit="1"/>
-</imageobject>
-<textobject><phrase>newclasswizard</phrase></textobject>
-</mediaobject>
-</informalfigure>
-</section>
-<section xml:id="field-properties">
-<title>Field Properties</title>
-<simpara><anchor xml:id="Class_File_Wizard-Project_Field" xreflabel="[Class_File_Wizard-Project_Field]"/> The New N4JS Class wizard offers following fields:</simpara>
-<variablelist>
-<varlistentry>
-<term>Project</term>
-<listitem>
-<simpara>Specifies the containing project.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<requirement xml:id="GH-1413">
-<title>Project constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Project constraints</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Constraints</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>It is a path of a valid project in the current workspace</simpara>
-</listitem>
-<listitem>
-<simpara>This field must not be empty</simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Project browse button</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Project browse button</link> (ver. 1)</simpara>
- <simpara>
-
-Browse Button::
- Browsing only allows the selection of projects in the current workspace. Project creation is not possible.</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Project initial selection inference</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Project initial selection inference</link> (ver. 1)</simpara>
- <simpara>
-
-Initial selection::
- The project should be derived from the initial selection.</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Project content assist</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Project content assist</link> (ver. 1)</simpara>
- <simpara>
-
-Content Assist::
- Workspace projects</simpara>
-</requirement>
-<variablelist xml:id="Class_File_Wizard-Source_Folder_Field">
-<varlistentry>
-<term>Source folder</term>
-<listitem>
-<simpara>Specifies the containing source folder.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<requirement xml:id="GH-1413">
-<title>Source folder constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Source folder constraints</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Constraints</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The folder is listed as source folder in the project manifest</simpara>
-</listitem>
-<listitem>
-<simpara>This field must not be empty.</simpara>
-</listitem>
-<listitem>
-<simpara>The name is a valid path that means each segment of the path matches the following expression:</simpara>
-<programlisting language="ebnf" linenumbering="unnumbered">[a-zA-z_](([\\.][a-zA-z_0-9\\-])|[a-zA-z_0-9\\-])*</programlisting>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Source folder browse button</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Source folder browse button</link> (ver. 1)</simpara>
- <simpara>
-
-Browse Button::
- Browsing only allows the selection of source folders in the selected project. The dialog should provide a list of all source folders of the selected project. This includes nested source folders. A list element is a relative path of a source folder in the project.</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Source folder initial selection inference</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Source folder initial selection inference</link> (ver. 1)</simpara>
- <simpara>
-
-Initial selection::
- The source folder field should be derived from the initial selection</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Source folder content assist</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Source folder content assist</link> (ver. 1)</simpara>
- <simpara>
-
-Content Assist::
- source folders defined by the project manifest</simpara>
-</requirement>
-<variablelist xml:id="Class_File_Wizard-Module_Specifier_Field">
-<varlistentry>
-<term>Module specifier</term>
-<listitem>
-<simpara>Specifies the module specifier. May only specify a module container (a folder) but could also include module name. May also be an already existing module. Does not include the file extension.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<requirement xml:id="GH-1413">
-<title>Module specifier constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Module specifier constraints</link> (ver. 1)</simpara>
- <simpara>
-
-The specifier is a valid module specifier that is
-- Segments are separated by the path separator
-- No separator at the beginning or end</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Module specifier completion</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Module specifier completion</link> (ver. 1)</simpara>
- <simpara>
-
-Manually inserting a specifier ending with a separator is valid.
-It is then interpreted as base path for the full module specifier automatically completed by the class name. (cf. grey suffix)</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Module specifier grey suffix</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Module specifier grey suffix</link> (ver. 1)</simpara>
- <simpara>
-
-A grey suffix should suggest the attached class name as module name if the specifier only specifies a base path.</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Module specifier browse button</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Module specifier browse button</link> (ver. 1)</simpara>
- <simpara>
-
-Browsing only allows the selection of modules or module containers in the selected source folder. The browse dialog has to offer a module container creation functionality. In contrast to the other parts of the wizard, the creation of module containers in this dialog should be immediate and on file system level. This is important to comply with the conceptual model of eclipse and the operating system.</simpara>
-<simpara>When inserting a non-existent path in the text input and opening the browse dialog, an additional dialog should ask the user whether he wants to create this structure on the file system. If he denies, the dialog shows the selection to the level it already exists on the file system.</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Module specifier initial selection inference</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Module specifier initial selection inference</link> (ver. 1)</simpara>
- <simpara>
-
-The module specifier should be derived from the initial selection by using the container of the selection as initial module container</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Module specifier content assist</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Module specifier content assist</link> (ver. 1)</simpara>
- <simpara>
-
-Modules in the selected source folder</simpara>
-</requirement>
-<simpara role="todo">For now the spec doesn’t specify any constraints for module specifiers</simpara>
-<variablelist>
-<varlistentry>
-<term>Class name</term>
-<listitem>
-<simpara>Specifies the class name.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<requirement xml:id="GH-1413">
-<title>Class name basic constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Class name basic constraints</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Constraints</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The name is a valid n4js class identifier Must not be empty</simpara>
-</listitem>
-<listitem>
-<simpara>If the target module already exists no other type with the same identifier may exist in this module</simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Class name conflict validation</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Class name conflict validation</link> (ver. 1)</simpara>
- <simpara>
-
-If the target module already exists no other type with the same identifier may exist in this module</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>File type options</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">File type options</link> (ver. 1)</simpara>
- <simpara>
-
-Definition file (.n4jsd):: Specifies whether the class should be declared external. This option changes the file extension to <literal>n4jsd</literal></simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Access modifier constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Access modifier constraints</link> (ver. 1)</simpara>
- <simpara>
-
-Specifies the access modifiers of the class. One of <literal>public</literal>, <literal>project</literal>, <emphasis role="strong">private</emphasis>. <literal>@Internal</literal> is an additionally selectable option.</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Constraints</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>One of the provided access modifiers has to be selected</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal>@Internal</literal> option is only selectable in case of <literal>public</literal> or <literal>project</literal></simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</requirement>
-<variablelist>
-<varlistentry>
-<term>Other modifiers</term>
-<listitem>
-<simpara>Specifies other modifiers and annotations of the class. The non-exclusive options are <literal>@Final</literal> and <emphasis role="strong">@N4JS</emphasis></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<requirement xml:id="GH-1413">
-<title>Other modifiers constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Other modifiers constraints</link> (ver. 1)</simpara>
- <simpara>
-
-Constraints::
- 1. <emphasis role="strong">@N4JS</emphasis> annotation is only enabled and selectable if the Definition File box is checked</simpara>
-</requirement>
-<variablelist>
-<varlistentry>
-<term>Super class</term>
-<listitem>
-<simpara>Specifies the super class</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<requirement xml:id="GH-1413">
-<title>Super class constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Super class constraints</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Constraints</simpara>
-</entry>
-<entry>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A valid absolute class specifier that is a module specifier and a class name separated by a dot.</simpara>
-</listitem>
-</orderedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Super class browse button</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Super class browse button</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Browse Button</simpara>
-</entry>
-<entry>
-<simpara>Browsing allows the selection of all classes in the current workspace with modifiable source and visible classes with unmodifiable sources.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Super class content assist</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Super class content assist</link> (ver. 1)</simpara>
- <simpara>
-
-Content Assist::
- All classes matching mentioned criteria</simpara>
-</requirement>
-<variablelist xml:id="Class_File_Wizard-Interfaces_Field">
-<varlistentry>
-<term>Interfaces</term>
-<listitem>
-<simpara>Specifies the implemented interfaces of the class</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<requirement xml:id="GH-1413">
-<title>Interfaces constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Interfaces constraints</link> (ver. 1)</simpara>
- <simpara>
-
-1. A valid absolute interface specifier that is a module specifier and an interface name separated by a dot.</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Interfaces browsing</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Interfaces browsing</link> (ver. 1)</simpara>
- <simpara>
-
-Add Button:: Browsing allows the selection of all interfaces in the current workspace with modifiable source and visible interfaces with unmodifiable sources.</simpara>
-<variablelist>
-<varlistentry>
-<term>Remove Button</term>
-<listitem>
-<simpara>Removes the selected interface from the list. Disabled if nothing is selected.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Interfaces content assist</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Interfaces content assist</link> (ver. 1)</simpara>
- <simpara>
-
-Text input is available by clicking in empty space at the end of the list. Content Assist provides all interfaces matching mentioned criteria.</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Create method stubs</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Create method stubs</link> (ver. 1)</simpara>
- <simpara>
-
-Specifies if the wizard should generate method stubs for all abstract methods of the newly generated class. That are abstract super class methods or methods that need to be implemented by the class to conform to the selected interfaces.</simpara>
-</requirement>
-<requirement xml:id="GH-1413">
-<title>Create method stub conflict detection</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Create method stub conflict detection</link> (ver. 1)</simpara>
- <simpara>
-
-If the selected interfaces are impossible to implement (e.g. method name overlap with unrelated parameter types) this option needs to be disabled and a warning needs to be shown.</simpara>
-</requirement>
-<simpara role="todo">Shouldn’t this be a constraint of the selected interfaces? (Never generate invalid code)</simpara>
-</section>
-<section xml:id="visibility-issues-or-final-super-classes">
-<title>Visibility issues or <literal>@Final</literal> super classes</title>
-<requirement xml:id="GH-1413">
-<title>Visibility issue conflict solving</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Visibility issue conflict solving</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>By allowing the user to select invisible interfaces and super classes or unextendable <literal>@Final</literal>-annotated super classes, accessability issues may come up. The goal is to never generate a file containing invalid code. To accomplish this, conflicts must get solved before the file is generated.</simpara>
-<simpara>The slight limitation of the selection of interfaces and classes to elements from modifiable sources (cf. <link linkend="Req-GH-1413">super class browse button</link>) allows to solve all possibly occurring visibility issues.</simpara>
-<simpara>If the modifications by finishing the wizard do imply changes different from insertions and creations, a compare view is to be shown, giving the user an overview of the needed changes before they’re applied.</simpara>
-</requirement>
-</section>
-<section xml:id="generation-1">
-<title>Generation</title>
-<requirement xml:id="GH-1413">
-<title>Wizard generation</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Wizard generation</link> (ver. 1)</simpara>
- <simpara>
-
-The following changes are to be made by the wizard:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Create a new file containing the new class (optional)</simpara>
-</listitem>
-<listitem>
-<simpara>Insert the new class into the specified module</simpara>
-</listitem>
-<listitem>
-<simpara>Change the source module of the super class to fix possible visibility issues (optional)</simpara>
-</listitem>
-<listitem>
-<simpara>Change the source module of the interfaces to fix possible visibility issues (optional)</simpara>
-</listitem>
-<listitem>
-<simpara>Change the project manifest to add a new source folder (optional) or add new project dependencies (optional)</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="preview-1">
-<title>Preview</title>
-<requirement xml:id="GH-1413">
-<title>Generation preview</title>
-<simpara>
-<anchor xml:id="Req-GH-1413" xreflabel="[Req-GH-1413]"/>
-<emphasis role="strong">Requirement: GH-1413:</emphasis>
-<link linkend="Req-GH-1413">Generation preview</link> (ver. 1)</simpara>
- <simpara>
-
-On the right of the wizard form a preview window should be provided. It should preview the full path of the generated file and all code that is generated with the options of the wizard. Changes should be updated in realtime as the user is choosing different options.</simpara>
-</requirement>
-</section>
-</section>
-<section xml:id="sec:N4JS_Interface_Wizard">
-<title>Interface Wizard</title>
-<simpara>The N4JS interface wizards is strongly similar to the <link linkend="sec:N4JS_Class_File_Wizard">N4JS Class Wizard</link>. The following paragraph is meant to state the differences and will strongly refer to the N4JS Class Wizard as a lot of properties stay the same.</simpara>
-<informalfigure role="center">
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/06_wizards/fig/newinterfacewizard.png" width="60%" scalefit="1"/>
-</imageobject>
-<textobject><phrase>newinterfacewizard</phrase></textobject>
-</mediaobject>
-</informalfigure>
-<section xml:id="field-properties-1">
-<title>Field Properties</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Project</simpara>
-</entry>
-<entry>
-<simpara>Specifies the containing project.
-See <link linkend="Class_File_Wizard-Project_Field">N4JS Class Wizard Project</link>.</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Source Folder</simpara>
-</entry>
-<entry>
-<simpara>Specifies the containing source folder.<?asciidoc-br?>
-See <link linkend="Class_File_Wizard-Source_Folder_Field">N4JS Class Wizard Source Folder</link></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Module Specifier</simpara>
-</entry>
-<entry>
-<simpara>Specifies the containing source folder.<?asciidoc-br?>
-See <link linkend="Class_File_Wizard-Module_Specifier_Field">N4JS Class Wizard Module specifier</link></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Interface name</simpara>
-</entry>
-<entry>
-<simpara>Specifies the name of the interface<?asciidoc-br?></simpara>
-<variablelist>
-<varlistentry>
-<term>Constraints</term>
-<listitem>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The name is a valid n4js interface identifier</simpara>
-</listitem>
-<listitem>
-<simpara>Must not be empty</simpara>
-</listitem>
-<listitem>
-<simpara>If the target module already exists, no other type with the same identifier may exist in this module</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Definition file (.n4jsd)</simpara>
-</entry>
-<entry>
-<simpara>Specifies whether the interface should be declared external. This option changes the file extension to <literal>n4jsd</literal> .</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Access Modifiers</simpara>
-</entry>
-<entry>
-<simpara>Specifies the interface’s access modifiers</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>See <link linkend="Req-GH-1413">N4JS Class Wizard Modifier Field</link> except for the following point:</simpara>
-<simpara><emphasis>Other than classes, interfaces must not be declared as <literal>@Final</literal>, therefore this option is removed.</emphasis></simpara>
-<variablelist>
-<varlistentry>
-<term>Interfaces</term>
-<listitem>
-<simpara>The interfaces the interface is implementing</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>See <link linkend="Class_File_Wizard-Interfaces_Field">N4JS Class Wizard Interfaces field</link> except for the following point:</simpara>
-<simpara><emphasis>Other than classes interfaces must not be declared as <literal>@Final</literal>, therefore this option is removed.</emphasis></simpara>
-<variablelist>
-<varlistentry>
-<term>Create method stubs</term>
-<listitem>
-<simpara>Specifies if the wizard should generate method stubs for all abstract methods of the newly generated class. That are abstract super interface methods or methods that need to be implemented by the interface to conform to the given interfaces.</simpara>
-<simpara>If the selected interfaces are impossible to implement (e.g. method name overlap with unrelated parameter types) this option needs to be disabled and a warning needs to be shown.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara role="todo">Shouldn’t this be a constraint of the selected interfaces? (Never generate invalid code)</simpara>
-</section>
-<section xml:id="visibility-issues">
-<title>Visibility Issues</title>
-<simpara>As the user might select invisible interfaces, the wizard has to solve these visibility issues. See ** for details.</simpara>
-</section>
-<section xml:id="import-naming-conflicts">
-<title>Import naming conflicts</title>
-<simpara>As the user may select identically named interfaces, the wizard has to solve these naming conflicts. See
-<emphasis role="strong"><link linkend="Req-GH-1413">Class Wizard Visibility Issues</link></emphasis> for details.</simpara>
-</section>
-<section xml:id="generation-2">
-<title>Generation</title>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Create a new file at the given module specifier location (optional)</simpara>
-</listitem>
-<listitem>
-<simpara>Insert the new interface into the specified module</simpara>
-</listitem>
-<listitem>
-<simpara>Change the source module of the super class to fix visibility issues (optional)</simpara>
-</listitem>
-<listitem>
-<simpara>Change the source module of the interfaces to fix possible visibility issues (optional)</simpara>
-</listitem>
-<listitem>
-<simpara>Change the project manifest to add a possibly new source folder (optional) or add new project dependencies (optional)</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="preview-2">
-<title>Preview</title>
-<simpara>The Interface Wizard should provided a preview. (See <link linkend="sec:N4JS_Wizards:Wizard_Preview">Wizard Preview</link>)</simpara>
-</section>
-</section>
-<section xml:id="sec:N4JS_Enum_File_Wizard">
-<title>Enum Wizard</title>
-<simpara>The N4JS Enum File wizards provides the user a wizard to create enums. When speaking of enums in this context ordinary enums as specified in the N4JS Specification are meant.</simpara>
-<section xml:id="field-properties-2">
-<title>Field Properties</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>Project</simpara>
-</entry>
-<entry>
-<simpara>Specifies the containing project.<?asciidoc-br?>
-See <link linkend="Class_File_Wizard-Project_Field">N4JS Class Wizard Project</link></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Source Folder</simpara>
-</entry>
-<entry>
-<simpara> Specifies the containing source folder.<?asciidoc-br?>
-See <link linkend="Class_File_Wizard-Source_Folder_Field">N4JS Class Wizard Source Folder</link></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Module Specifier</simpara>
-</entry>
-<entry>
-<simpara>Specifies the containing source folder. See <link linkend="Class_File_Wizard-Module_Specifier_Field">N4JS Class Wizard Module specifier</link></simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Enum name</simpara>
-</entry>
-<entry>
-<simpara>Specifies the name of the interface<?asciidoc-br?></simpara>
-<variablelist>
-<varlistentry>
-<term>Constraints</term>
-<listitem>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The name is a valid n4js enum identifier</simpara>
-</listitem>
-<listitem>
-<simpara>Must not be empty</simpara>
-</listitem>
-<listitem>
-<simpara>If the target module already exists, no other type with the same identifier may exist in this module</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>Modifiers</simpara>
-</entry>
-<entry>
-<simpara>Specifies the interface’s access modifiers
-+
-Allows the user to select from following modifier options: <literal>public</literal>,<literal>project</literal>,<literal>private</literal>. The wizard automatically adds missing <literal>export</literal> if needed.
-+
-Furthermore the enum can be declared <literal>@Internal</literal> using a checkbox.</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara role="todo">Should the enum wizard also provide functionality to create enum literals?</simpara>
-</section>
-<section xml:id="generation-3">
-<title>Generation</title>
-<simpara>The following changes are to be made by the wizard:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Create a new file containing the new enum (optional, only if module doesn’t exists yet )</simpara>
-</listitem>
-<listitem>
-<simpara>Insert the new enum into the specified module</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="preview-3">
-<title>Preview</title>
-<simpara>The Enum Wizard should provided a preview. (See <link linkend="sec:N4JS_Wizards:Wizard_Preview">Wizard Preview</link>)</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_execution-support">
-<title>Execution Support</title>
-<warning>
-<simpara>Parts of this document may be outdated.</simpara>
-</warning>
-<section xml:id="sec:Non_UI_Execution">
-<title>Non-UI Execution</title>
-<section xml:id="sec:Non_UI_Debugging">
-<title>Non-UI Debugging</title>
-<simpara>not supported yet</simpara>
-</section>
-</section>
-<section xml:id="sec:UI_Execution">
-<title>UI Execution</title>
-<simpara>The N4JS IDE supports launching a file via a so called "runner". That is, a selected file is started as main
-file with Node.js or Chrome, depending on the available runners.</simpara>
-<warning>
-<simpara>Chrome support not available yet.</simpara>
-</warning>
-<simpara>For testing, a file, package, or even a whole project can be executed with a "tester". In that case, instead of directly executing the selected resource with Node.js (or other runners), the "mangelhaft" framework is used to run the selected resource or all its content as tests. For test support in general, see next chapter.</simpara>
-<simpara>Running or testing a resource is done via a launch configuration. This can be configured.</simpara>
-<simpara>The node.js runner/tester allows for configuration of</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the NODE_MODULE path. This can be adjusted if the automatically path is not suited.</simpara>
-</listitem>
-<listitem>
-<simpara>other environment variables (simply as key=value pairs per line)</simpara>
-</listitem>
-<listitem>
-<simpara>node.js options to be passed as arguments to node.js</simpara>
-</listitem>
-<listitem>
-<simpara>the system loader to be used, this is "System.js" by default</simpara>
-</listitem>
-</itemizedlist>
-<simpara>
-Since in the JavaScript world these configurations are often used, it is cumbersome, particularly for tests, to define them for every single file. Thus the N4JS IDE copies the node.js settings found in a project launch configuration to a resource specific launch configuration.</simpara>
-<sidebar>
-<simpara><link xl:href="https://github.com/eclipse/n4js/issues/716"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #716</link></simpara>
-</sidebar>
-</section>
-</chapter>
-<chapter xml:id="_test-support">
-<title>Test Support</title>
-<simpara>N4IDE provides tests support by allowing different <emphasis>TestRunner</emphasis>s to extend it with test specific functionality. This allows to support specialized and very different from each other test requirements (e.g. nodejs based tests, browser based interactive ui tests, server integration tests).</simpara>
-<figure xml:id="fig:test_support_diagram">
-<title>Test Support Diagram</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/09_testsupport/fig/cd_testsupport.png"/>
-</imageobject>
-<textobject><phrase>cd testsupport</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Explanation of the main components:</simpara>
-<variablelist>
-<varlistentry>
-<term><emphasis>User Project</emphasis></term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara>a project with production code (e.g. <literal>src</literal> folder), and test code (e.g. test folder)</simpara>
-</listitem>
-<listitem>
-<simpara>test code may contain special language features contributed by <emphasis>Test Library</emphasis></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis>N4IDE</emphasis></term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara>manage user project, including all test related parts (e.g. support test related code, validate some test code constraints)</simpara>
-</listitem>
-<listitem>
-<simpara>host runner, allow its UI contributions</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis>Test Runner</emphasis></term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara>contribute to N4IDE necessary elements (test results view, user test selection, test start/stop actions)</simpara>
-</listitem>
-<listitem>
-<simpara>use N4IDE mechanisms to access user project test fragment (e.g. discover tests)</simpara>
-</listitem>
-<listitem>
-<simpara>configure <emphasis>Test Execution Environment</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara>manage test runtime (e.g. start/stop execution environment)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis>Test Execution Environment</emphasis></term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara>hosts (directly or indirectly) js engine in which tests are executed</simpara>
-</listitem>
-<listitem>
-<simpara>executes test library logic</simpara>
-</listitem>
-<listitem>
-<simpara>is responsible for some tests execution aspects (e.g. test isolation)</simpara>
-</listitem>
-<listitem>
-<simpara>deals with some execution errors (e.g. no callback from async test, infinite loop in test)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><emphasis>Test Library</emphasis></term>
-<listitem>
-<itemizedlist>
-<listitem>
-<simpara>provides test api that user can use in his project</simpara>
-</listitem>
-<listitem>
-<simpara>coordinates scheduling and test code execution (e.g. order of tests, execution of setups / teardowns)</simpara>
-</listitem>
-<listitem>
-<simpara>creates test results</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Below picture and listings depicts the components of the Test Runner in the IDE:</simpara>
-<figure xml:id="fig:test_runner_components">
-<title>Test Runner Components</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/09_testsupport/fig/test_runner_components.png" width="75%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>test runner components</phrase></textobject>
-</mediaobject>
-</figure>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara><emphasis>Test Delegate</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>After the test discovery it starts and stops the test session via the Test Facade.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>Test Facade</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>Ensures that an embedded HTTP server is running to receive messages from the Test Execution Environment. Registers a test session into the IDE side via the Test Finite State Machine Registry and triggers the actual test running at Test Execution Environment.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>HTTP Server</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>HTTP server is listening for HTTP requests from the Test Execution Environment via its RESTful API.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>Resource Router Servlet</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>This servlet is deployed into the servlet container of the HTTP Server. The servlet percepts the HTTP requests from the Test Execution Environment and delegates the request body to the corresponding REST Endpoint Logic.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>REST Endpoint Logic</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>Parses the HTTP request bodies, creates special events and sends them to all subscribers via the Test Event Bus.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>Test Event Bus</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>This component is used to asynchronously deliver messages between the main test runner components in a decoupled fashion.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>Test Finite State Machine Registry</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>This registry is used to cache test sessions represented as test trees and Test Finite State Machines. Percepts all messages initially sent by the Test Execution Environment and delegates them to the corresponding subscribers.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>Test Finite State Machine</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>Ensures the lifecycle of a test session. Handles timeouts duo to possible communication errors between the HTTP server and the Test Execution Environment.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>Test Tree Registry</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>Registry to handle the state of a test session. Responsible for updating a test tree associated with a test session with the received test results.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-<row>
-<entry>
-<simpara><emphasis>Test UI</emphasis></simpara>
-</entry>
-<entry>
-<itemizedlist>
-<listitem>
-<simpara>This UI component provides feedback about the running test session to the end-user.</simpara>
-</listitem>
-</itemizedlist>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<section xml:id="sec:N4JS_Mangelhaft_support" role="language-n4js">
-<title>N4JS Mangelhaft support</title>
-<figure xml:id="fig:xUnitSupportDesign" role="center">
-<title>xUnit Support Design</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/09_testsupport/fig/xUnitSupportDesign.png" width="75%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>xUnitSupportDesign</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>In this section and subsections we specify N4IDE support for testing with Mangelhaft.</simpara>
-<simpara>Mangelhaft is N4JS <emphasis>Test Library</emphasis>. It is focused more on a xUnit tests than other forms of testing (BDD, Acceptance Testing, Functional UI Testing).</simpara>
-<simpara>The following test scenarios are supported on different <emphasis>Test Execution Environment</emphasis>s:</simpara>
-<table xml:id="tab:Test_Scenarios" frame="all" rowsep="1" colsep="1">
-<title>Test Scenarios</title>
-<tgroup cols="4">
-<colspec colname="col_1" colwidth="25*"/>
-<colspec colname="col_2" colwidth="25*"/>
-<colspec colname="col_3" colwidth="25*"/>
-<colspec colname="col_4" colwidth="25*"/>
-<thead>
-<row>
-<entry align="center" valign="top">Test</entry>
-<entry align="center" valign="top">Node</entry>
-<entry align="center" valign="top">Browser</entry>
-<entry align="center" valign="top">Wrapper</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Plain</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>yes</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>yes</literal></simpara></entry>
-<entry align="center" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">DOM</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>yes</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">non-interactive UI</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">interactive UI (iUI)</emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">(non UI) Server</emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">iUI Server</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>-</literal></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<section xml:id="sec:Asynchronous_Tests">
-<title>Asynchronous Tests, Test Isolation and Timeouts</title>
-<simpara>A special problem about JavaScript tests is to control asynchronous tests and non-terminating tests.</simpara>
-<simpara>Performance and test isolation are conflicting goals: a perfect isolation would mean to run every tests by a separate JavaScript engine, which is not performant. For that reason, all tests are run by the same JS-engine in general. A test has to notify the test runner when it has been finished (successfully or with failure). If it does not finish in a defined time (timeout), <emphasis>Test Execution Environment</emphasis> or <emphasis>Manglehaft</emphasis> needs to handle that (e.g. restart node vm in which code is executed)…​</simpara>
-<simpara>Main concerns with running test in parallel on js side are:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Timeouts Mangelhaft is supposed to track test timeout. If tests are running in fake parallel mode achieved by cooperative multitasking, then one test running eats up time for other test. This can cause tests to timeout when running in parallel, while succeed when running in sequential mode.</simpara>
-</listitem>
-<listitem>
-<simpara>Mutability on client. Tests running in parallel can affect each other by mutating global state in which they operate. When they run in sequential mode this can happen too, but it is much less likely to.</simpara>
-</listitem>
-<listitem>
-<simpara>Mutable state on the server. Tests running on the same session/login are prone to affecting each other through server interaction (and or mutating data on the server).</simpara>
-</listitem>
-</orderedlist>
-</section>
-<section xml:id="sec:Supported_xUnit_API">
-<title>Supported xUnit API</title>
-<simpara>xUnit API is user facing API for defining tests. It allows test developer to define tests and configure some test execution aspects. N4IDE (via <emphasis>Test Runner</emphasis> extension) supports defined API by :</simpara>
-<itemizedlist>
-<listitem>
-<simpara>gathering information via AST analysis and reflection</simpara>
-</listitem>
-<listitem>
-<simpara>presenting user available actions, based on gathered information</simpara>
-</listitem>
-<listitem>
-<simpara>gathering user input and configurations for test execution</simpara>
-</listitem>
-<listitem>
-<simpara>generating proper data for test infrastructure, based on user actions</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="sec:Test_Group">
-<title>Test Group</title>
-<simpara>A test group is a logical collection of tests. It is created by grouping <literal>N4ClassDeclarations</literal> that contain test methods or test methods directly (see <link linkend="sec:Test_Method">Test Method</link>). Those classes or individual methods can be assigned to a <emphasis>Group</emphasis> by annotating them with <literal>@Group</literal> annotation. This annotation takes non empty list of strings as parameter. Passed strings are used as category name (which is like its id).</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:
- '@Group'
- (' $group+=$STRING ')?
- AnnotatedElement
-;
-
-AnnnotatedElement:
- N4JSClassDeclaration | N4JSMethodDeclaration
-;</programlisting>
-<simpara><literal>@Group</literal> properties</simpara>
-<itemizedlist>
-<listitem>
-<simpara>name → <literal>Group</literal></simpara>
-</listitem>
-<listitem>
-<simpara>targets → N4Method, N4Class</simpara>
-</listitem>
-<listitem>
-<simpara>retention policy → RUNTIME</simpara>
-</listitem>
-<listitem>
-<simpara>transitive → YES</simpara>
-</listitem>
-<listitem>
-<simpara>repeatable → YES</simpara>
-</listitem>
-<listitem>
-<simpara>arguments → <emphasis>String</emphasis>s</simpara>
-</listitem>
-<listitem>
-<simpara>arguments are optional → NO</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Test_Method">
-<title>Test Method</title>
-<simpara><emphasis>Test Method</emphasis> marks procedure that has to be executed by <emphasis>Test Library</emphasis>.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:
- '@Test'
- AnnotatedElement
-;
-
-AnnnotatedElement:
- N4JSMethodDeclaration
-;</programlisting>
-<simpara><literal>@Test</literal> properties</simpara>
-<itemizedlist>
-<listitem>
-<simpara>name → <literal>Test</literal></simpara>
-</listitem>
-<listitem>
-<simpara>targets → N4Method</simpara>
-</listitem>
-<listitem>
-<simpara>retention policy → RUNTIME</simpara>
-</listitem>
-<listitem>
-<simpara>transitive → NO</simpara>
-</listitem>
-<listitem>
-<simpara>repeatable → NO</simpara>
-</listitem>
-<listitem>
-<simpara>arguments → none</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Additional <emphasis>TestMethod</emphasis> constraints:</simpara>
-<simpara>Test Method <anchor xml:id="cnst:Test_Method" xreflabel="[cnst:Test_Method]"/></simpara>
-<itemizedlist>
-<listitem>
-<simpara>allowed only <literal>N4ClassDeclarations</literal> in project test fragment</simpara>
-</listitem>
-<listitem>
-<simpara>method must be public</simpara>
-</listitem>
-<listitem>
-<simpara>method takes no parameters</simpara>
-</listitem>
-<listitem>
-<simpara>method return type is <literal>Promise?</literal></simpara>
-</listitem>
-<listitem>
-<simpara>method must not be referenced by other owning class members or other classes (also no <emphasis>@override</emphasis>)</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:BeforeAll">
-<title>BeforeAll Setup</title>
-<simpara><literal>@BeforeAll</literal> marks method that will be executed once before <emphasis role="strong">all</emphasis> tests in a given test class will be executed.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:
- '@BeforeAll'
- AnnotatedElement
-;
-
-AnnnotatedElement:
- N4JSMethodDeclaration
-;</programlisting>
-<simpara><literal>@BeforeAll</literal> properties</simpara>
-<itemizedlist>
-<listitem>
-<simpara>name → <literal>BeforeAll</literal></simpara>
-</listitem>
-<listitem>
-<simpara>targets → N4Method</simpara>
-</listitem>
-<listitem>
-<simpara>retention policy → RUNTIME</simpara>
-</listitem>
-<listitem>
-<simpara>transitive → NO</simpara>
-</listitem>
-<listitem>
-<simpara>repeatable → NO</simpara>
-</listitem>
-<listitem>
-<simpara>arguments → none</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The same constraints apply as for the test method, see <link linkend="cnst:Test_Method">Test Method Constraints</link>.</simpara>
-</section>
-<section xml:id="sec:Before_Setup">
-<title>Before Setup</title>
-<simpara><literal>@Before</literal> marks method that will be executed once before <emphasis role="strong">each</emphasis> tests in a given test class will be executed.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:
- '@Before'
- AnnotatedElement
-;
-
-AnnnotatedElement:
- N4JSMethodDeclaration
-;</programlisting>
-<simpara><literal>@Before</literal> properties</simpara>
-<itemizedlist>
-<listitem>
-<simpara>name → <literal>Before</literal></simpara>
-</listitem>
-<listitem>
-<simpara>targets → N4Method</simpara>
-</listitem>
-<listitem>
-<simpara>retention policy → RUNTIME</simpara>
-</listitem>
-<listitem>
-<simpara>transitive → NO</simpara>
-</listitem>
-<listitem>
-<simpara>repeatable → NO</simpara>
-</listitem>
-<listitem>
-<simpara>arguments → none</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The same constraints apply as for the test method, see <link linkend="cnst:Test_Method">Test Method Constraints</link>.</simpara>
-</section>
-<section xml:id="sec:After_Teardown">
-<title>After Teardown</title>
-<simpara><literal>@After</literal> marks method that will be executed once after <emphasis role="strong">each</emphasis> tests in a given test class will be executed.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:
- '@After'
- AnnotatedElement
-;
-
-AnnnotatedElement:
- N4JSMethodDeclaration
-;</programlisting>
-<simpara><literal>@After</literal> properties</simpara>
-<itemizedlist>
-<listitem>
-<simpara>name → <literal>After</literal></simpara>
-</listitem>
-<listitem>
-<simpara>targets → N4Method</simpara>
-</listitem>
-<listitem>
-<simpara>retention policy → RUNTIME</simpara>
-</listitem>
-<listitem>
-<simpara>transitive → NO</simpara>
-</listitem>
-<listitem>
-<simpara>repeatable → NO</simpara>
-</listitem>
-<listitem>
-<simpara>arguments → none</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The same constraints apply as for the test method, see <link linkend="cnst:Test_Method">Test Method Constraints</link>.</simpara>
-</section>
-<section xml:id="sec:AfterAll_Teardown">
-<title>AfterAll Teardown</title>
-<simpara><literal>@AfterAll</literal> marks method that will be executed once after <emphasis role="strong">all</emphasis> tests in a given test class will be executed.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:
- '@After'
- AnnotatedElement
-;
-
-AnnnotatedElement:
- N4JSMethodDeclaration
-;</programlisting>
-<itemizedlist mark="Test Fixture][cnst:Test_Fixture">
-<listitem>
-<simpara>allowed only in class marked with <emphasis>@TestClass</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara>method must be public</simpara>
-</listitem>
-<listitem>
-<simpara>method takes no parameters</simpara>
-</listitem>
-<listitem>
-<simpara>method return type is <literal>void</literal></simpara>
-</listitem>
-<listitem>
-<simpara>method must not be referenced by other owning class members</simpara>
-</listitem>
-</itemizedlist>
-<simpara><literal>@AfterAll</literal> properties</simpara>
-<itemizedlist>
-<listitem>
-<simpara>name → <literal>AfterAll</literal></simpara>
-</listitem>
-<listitem>
-<simpara>targets → N4Method</simpara>
-</listitem>
-<listitem>
-<simpara>retention policy → RUNTIME</simpara>
-</listitem>
-<listitem>
-<simpara>transitive → NO</simpara>
-</listitem>
-<listitem>
-<simpara>repeatable → NO</simpara>
-</listitem>
-<listitem>
-<simpara>arguments → none</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The same constraints apply as for the test method, see <link linkend="cnst:Test_Method">Test Method Constraints</link>.</simpara>
-</section>
-<section xml:id="sec:Test_Ignore">
-<title>Test Ignore</title>
-<informaltable tabstyle="horizontal" frame="none" colsep="0" rowsep="0">
-<tgroup cols="2">
-<colspec colwidth="15*"/>
-<colspec colwidth="85*"/>
-<tbody valign="top">
-<row>
-<entry>
-<simpara>name</simpara>
-</entry>
-<entry>
-<simpara>@Ignore</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>targets</simpara>
-</entry>
-<entry>
-<simpara>N4Method, N4Class</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>retention policy</simpara>
-</entry>
-<entry>
-<simpara>RUNTIME</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>transitive</simpara>
-</entry>
-<entry>
-<simpara>YES</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>repeatable</simpara>
-</entry>
-<entry>
-<simpara>NO</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>arguments</simpara>
-</entry>
-<entry>
-<simpara>String reason</simpara>
-</entry>
-</row>
-<row>
-<entry>
-<simpara>arguments are optional</simpara>
-</entry>
-<entry>
-<simpara>→ Yes</simpara>
-</entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><emphasis>Test Ignore</emphasis> allows to mark tests that should be skipped during the test execution. That is the preferred way to temporarily disable tests without removing them (or commenting them out). Test developers may provide reason for skipping to make reason/intentions clearer.</simpara>
-<simpara>This annotation is <emphasis>transitive</emphasis>, which means that: <emphasis>Test Method</emphasis> is considered as marked with <emphasis>Test Skip</emphasis></simpara>
-<itemizedlist>
-<listitem>
-<simpara>explicitly when it is directly marked or</simpara>
-</listitem>
-<listitem>
-<simpara>implicitly, when container of a <emphasis>Test Method</emphasis> is marked.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If a class is marked as <literal>@Ignore</literal>, then all its contained test methods will be ignored.<?asciidoc-br?>
-When <literal>@Ignore</literal> occurs at class level in a test class hierarchy chain, then the following rules are applied. Assume the following test classes:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">export public class A {
-
- @Test
- public aTest(): void {
- console.log('A#aTest');
- }
-
-}</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">import { A } from "A"
-
-@Ignore('Class B is ignored.')
-export public class B extends A {
-
- @Test
- public b1Test(): void {
- console.log('B#b1Test');
- }
-
- @Ignore("Method B#b2Test is ignored.")
- @Test
- public b2Test(): void {
- console.log("B#b2Test");
- }
-
-}</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">import { B } from "B"
-
-export public class C extends B {
-
- @Test
- public cTest(): void {
- console.log('C#cTest');
- }
-
-}</programlisting>
-<itemizedlist>
-<listitem>
-<simpara>When module <emphasis>A</emphasis> is being tested, then it is obvious that all the test methods of <literal>A</literal> will be tested. No methods will be skipped at all.</simpara>
-</listitem>
-<listitem>
-<simpara>When module <emphasis>B</emphasis> is being tested, then although the inherited members of class <literal>A</literal> will be included in the test tree, all methods, including the inherited ones (from class <literal>A</literal> from module <emphasis>A</emphasis>) will be skipped. Nothing will be tested.</simpara>
-</listitem>
-<listitem>
-<simpara>When module <emphasis>C</emphasis> is being tested, then all inherited members from class <literal>B</literal> and class <literal>A</literal> will be collected an included in the test tree. The <literal>@Ignore</literal> annotation declared at class level at <literal>B</literal> will be ignored but the <literal>@Ignore</literal> at method level in class <literal>B</literal> will be considered. In a nutshell, the following methods will be executed:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>A#aTest</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>B#b1Test</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>C#cTest</literal></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-<simpara>The above described behavior is identical to the behavior of <emphasis>JUnit 4</emphasis> with respect to the <literal>@Ignore</literal> annotation handling in case of test class inheritance.</simpara>
-</section>
-<section xml:id="sec:Timeout">
-<title>Timeout</title>
-<simpara><emphasis>Timeout</emphasis> allows test developer to set custom timeout when executing given test code. This can be used to set timeout for both <emphasis>Test Method</emphasis>s or <emphasis>Test Fixtures</emphasis></simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:
- '@Timeout'
- ($timoeout+=$INT)?
- AnnotatedElement
-;
-
-AnnnotatedElement:
- N4JSClassDeclaration | N4JSMethodDeclaration
-;</programlisting>
-<simpara><literal>@Timeout</literal> properties</simpara>
-<itemizedlist>
-<listitem>
-<simpara>name → <literal>Timeout</literal></simpara>
-</listitem>
-<listitem>
-<simpara>targets → N4Method, N4Class</simpara>
-</listitem>
-<listitem>
-<simpara>retention policy → RUNTIME</simpara>
-</listitem>
-<listitem>
-<simpara>transitive → YES</simpara>
-</listitem>
-<listitem>
-<simpara>repeatable → NO</simpara>
-</listitem>
-<listitem>
-<simpara>arguments → Number</simpara>
-</listitem>
-<listitem>
-<simpara>arguments are optional → NO</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Description">
-<title>Description</title>
-<simpara><emphasis>Description</emphasis> allows test developer provide string describing given test or test class that <emphasis>can</emphasis> be used in IDE test view or in the test report.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:
- '@Description'
- ($desc+=$STRING)?
- AnnotatedElement
-;
-
-AnnnotatedElement:
- N4JSClassDeclaration | N4JSMethodDeclaration
-;</programlisting>
-<simpara><literal>@Description</literal> properties</simpara>
-<itemizedlist>
-<listitem>
-<simpara>name → <literal>Description</literal></simpara>
-</listitem>
-<listitem>
-<simpara>targets → N4Method, N4Class</simpara>
-</listitem>
-<listitem>
-<simpara>retention policy → RUNTIME</simpara>
-</listitem>
-<listitem>
-<simpara>transitive → YES</simpara>
-</listitem>
-<listitem>
-<simpara>arguments → String</simpara>
-</listitem>
-<listitem>
-<simpara>arguments are optional → NO</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-</section>
-<section xml:id="sec:Test_Reporting">
-<title>Test Reporting</title>
-<simpara><emphasis>Test Runtime Environment</emphasis> communicates with <emphasis>Test Runner</emphasis> over HTTP. Defined communication is based on protocol used between lupenrein and old ide. It is used to send the information about test execution progress from the <emphasis>Test Runtime</emphasis> to <emphasis>Test Runner</emphasis>. Information send by this protocol is not equivalent to test results. <emphasis>Test Runner</emphasis> interprets progress it receives and based on gathered information it generates test results. Under specific conditions <emphasis>Test Runner</emphasis> may change reported test status PASS to test result FAILED and put this information to the test report e.g. when timeout happens (see note on timeouts below).</simpara>
-<figure xml:id="fig:sm_TestListener" role="center">
-<title>TestListener</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/09_testsupport/fig/sm_TestListener.png" width="25%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>sm TestListener</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><link linkend="fig:sm_TestListener">Test Listener</link> shows Communication flow expected by the <emphasis>Test Runner</emphasis>. When the <emphasis>Test Runner</emphasis> is started first it waits for <emphasis>Start Session</emphasis> message. Next <emphasis>Test Tree</emphasis> message is expected. This describes list of all tests that are expected to be executed. For all tests in the list <emphasis>Test Runner</emphasis> expects <emphasis>Test Start</emphasis> and <emphasis>Test End</emphasis> message to be received. <emphasis>End Session</emphasis> is expected to be last message in the test session. <emphasis>Ping</emphasis> message can be send multiple times in between other messages to manage synchronization issues between <emphasis>Test Runner</emphasis> and <emphasis>Test Runtime</emphasis> (see below).</simpara>
-<simpara>Since all communication is asynchronous, IDE <emphasis>Test Runner</emphasis> must assume some timeout values that will define standard wait time during communication:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Initial 90s timeout to wait for the <emphasis>Start Session</emphasis> message. It may be fixed or adjusted to given environment (local/remote) and project (library/application).</simpara>
-</listitem>
-<listitem>
-<simpara>Default timeout between all other test messages is 10 seconds. <emphasis>Test Runtime</emphasis> may notify IDE <emphasis>Test Runner</emphasis> that it should wait longer with <emphasis>Ping</emphasis> <emphasis>test message</emphasis>. This is one time thing, as soon as another command is received the default timeout will have to be reused again.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Do to the asynchronous nature of the tests, status updates can be given out of order by the Test Runtime Environment. The only sure thing is that all tests begin with <emphasis>SessionStart</emphasis> and ends with a <emphasis>SessionEnd</emphasis>. Furthermore a <emphasis>TestStart</emphasis> will be send before the <emphasis>TestEnd</emphasis> for a particular test.</simpara>
-<section xml:id="sec:Test_Messages">
-<title>Test Messages</title>
-<simpara>IDE <emphasis>Test Runner</emphasis> will be waiting for specific messages from <emphasis>Test Runtime</emphasis>. We assume that communication will be done over HTTP protocol. <emphasis>Test Execution Environement</emphasis> should be configured by the <emphasis>Test Runner</emphasis> in a way that <emphasis>Test Runtime</emphasis> knows address where it has to send messages (see
-<link linkend="sec:Test_Runtime_Configuration">Test Runtime Configuration</link>). <emphasis>Test Runner</emphasis> exposes RESTful API allowing him to receive messages. Below we define parts of that api that enable specific messages to be communicated.</simpara>
-<simpara>When defining <emphasis>Test Message</emphasis>s we assume following model of tests:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">TestTree {
- ID sessionId,
- Array<TestSuite>? testSuites
-}
-
-TestSuite {
- string name,
- Array<TestCase>? testCases,
- Array<TestSuite>? children
-}
-
-TestCase {
- ID id,
- string className,
- string origin,
- string name,
- string displayName,
- TestResult? result
-}
-
-TestResult {
- TestStatus teststatus,
- number elapsed,
- string? expected,
- string? actual,
- string? message,
- array<string>? trace
-}
-
-enum TestStatus {
- PASSED, SKIPPED, FAILED, ERROR
-}
-
-ID {
- string value
-}</programlisting>
-<section xml:id="_test-case-ids">
-<title>Test Case IDs</title>
-<simpara>The ID of a test case in the following specifications is referred to as <literal>testID</literal>.
-This ID is of the following structure:</simpara>
-<screen>testID: fqn '#' methodName</screen>
-<simpara>When used as part of the URL the testID is percent-escaped as defined in <link xl:href="https://tools.ietf.org/html/rfc3986#section-2.1">RFC3986 Section 2.1</link>. This is necessarry to circumvent the fact that the N4JS FQN delimiter <literal>/</literal> is a reserved character in URLs and cannot be used in its original form.</simpara>
-</section>
-<section xml:id="sec:Start_Session">
-<title>Start Session</title>
-<simpara>Signals start of the test session. When user triggers test execution, configures <emphasis>IDETestRunnerCtrl</emphasis>, afterwards IDE <emphasis>Listener</emphasis> waits for this message from <emphasis>TestRunner</emphasis>.</simpara>
-<programlisting language="json" linenumbering="unnumbered">StartSession :
- uri : /n4js/testing/sessions/{sessionID}/start
- method : POST
- contentType : application/vnd.n4js.start_session_req.tm+json
- accept: application/json
- responses:
- 200:
- 400:</programlisting>
-<simpara>Start session request object MIME type <emphasis>application/vnd.n4js.start_session_req.tm+json</emphasis>:</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- map<string, string>? properties
-}</programlisting>
-</section>
-<section xml:id="sec:Ping_Session">
-<title>Ping Session</title>
-<simpara>Signals that test runner is still busy doing things, and will report later to the listener.</simpara>
-<programlisting language="json" linenumbering="unnumbered">PingSession :
- uri : /n4js/testing/sessions/{sessionID}/ping
- method : POST
- contentType : application/vnd.n4js.ping_session_req.tm+json
- accept: application/json
- responses:
- 200:
- 400:</programlisting>
-<simpara>Ping session request object MIME type <emphasis>application/vnd.n4js.ping_session_req.tm+json</emphasis>:</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- number timeout,
- string? comment
-}</programlisting>
-</section>
-<section xml:id="sec:End_Session">
-<title>End Session</title>
-<simpara>Signals end of test session Notifies IDE <emphasis>Listener</emphasis> that session is finished and no further related <emphasis>TestMessage</emphasis>s are expected. IDE, can stop listening and proceed with its own tasks (e.g. create summary test report ).</simpara>
-<programlisting language="json" linenumbering="unnumbered">EndSession :
- uri : /n4js/testing/sessions/{sessionID}/end
- method : POST
- responses:
- 200:
- 400:</programlisting>
-</section>
-<section xml:id="sec:Start_Test">
-<title>Start Test</title>
-<simpara>Signals that a test run has started. Updates the state of the test reported with the <emphasis>tree</emphasis> .</simpara>
-<programlisting language="json" linenumbering="unnumbered">StartTest :
- uri : /n4js/testing/sessions/{sessionID}/tests/{testID}/start
- method : POST
- contentType : application/vnd.n4js.start_test_req.tm+json
- accept: application/json
- responses:
- 200:
- contentType : application/vnd.n4js.start_test_res.tm+json
- 400:</programlisting>
-<simpara>Start test request object MIME type <emphasis>application/vnd.n4js.start_test_req.tm+json</emphasis>:</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- number timeout,
- map<string, string>? properties
-}</programlisting>
-<simpara>Start test response object MIME type <emphasis>application/vnd.n4js.start_test_res.tm+json</emphasis>:</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- links : [
- {
- rel: "ping test",
- uri: "/n4js/testing/sessions/{sessionID}/tests/{testID}/ping"
- },
- {
- rel: "end test",
- uri: "/n4js/testing/sessions/{sessionID}/tests/{testID}/end"
- }
- ]
-}</programlisting>
-</section>
-<section xml:id="sec:End_Test">
-<title>End Test</title>
-<simpara>Signals that a test run has ended. Updates the state of the test reported with the <emphasis>tree</emphasis> .</simpara>
-<programlisting language="json" linenumbering="unnumbered">EndTest :
- uri : /n4js/testing/sessions/{sessionID}/tests/{testID}/end
- method : POST
- contentType : application/vnd.n4js.end_test_req.tm+json
- accept: application/json
- responses:
- 200:
- 400:</programlisting>
-<simpara>End test request object MIME type <emphasis>application/vnd.n4js.end_test_req.tm+json</emphasis>:</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- TestResult result
-}</programlisting>
-</section>
-<section xml:id="sec:Ping_Test">
-<title>Ping Test</title>
-<simpara>Notifies IDE that <emphasis>TestRunner</emphasis> is doing something (e.g. test setup/teardown code, long running test). Without this notification IDE might interpret long pause in received messages as timeout, <emphasis>TestRunner</emphasis> crash or other issues (in consequence it might terminate whole test execution environment).</simpara>
-<programlisting language="json" linenumbering="unnumbered">PingTest :
- uri : /n4js/testing/sessions/{sessionID}/tests/{testID}/ping
- method : POST
- contentType : application/vnd.n4js.ping_test_req.tm+json
- accept: application/json
- responses:
- 200:
- 400:</programlisting>
-<simpara>Ping test request object MIME type <emphasis>application/vnd.n4js.ping_test_req.tm+json</emphasis>:</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- number timeout,
- string? comment
-}</programlisting>
-</section>
-<section xml:id="sec:Test_Catalog">
-<title>Test Catalog</title>
-<simpara>Assembles and returns with the test catalog representing all the tests available in the underlying <emphasis>IN4JSCore</emphasis> specific workspace. The content of the test catalog is calculated dynamically. The test catalog calculation depends on the current built state of the workspace. If the workspace was cleaned and not built yet, then a test catalog containing zero test suites (and test cases) will be provided as a response. If the workspace is built and in consistent state, then a catalog containing all test cases will be sent as the response body. The provided test catalog format complies to the Mangelhaft reporters.</simpara>
-<programlisting language="json" linenumbering="unnumbered">TestCatalog :
- uri : /n4js/testing/sessions/testcatalog
- method : GET
- contentType : application/vnd.n4js.assemble_test_catalog_req.tm+json
- accept: application/json
- responses:
- 200:
- 400:</programlisting>
-<simpara>Below listings represents an example of the test catalog format:</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- "endpoint": "http://localhost:9415",
- "sessionId": "fc3a425c-b675-47d7-8602-8877111cf909",
- "testDescriptors": [
- {
- "origin": "SysProjectA-0.0.1",
- "fqn": "T/T",
- "testMethods": [
- "t"
- ]
- },
- {
- "origin": "TestProjectA-0.0.1",
- "fqn": "A/A",
- "testMethods": [
- "a"
- ]
- },
- {
- "origin": "TestProjectA-0.0.1",
- "fqn": "B/B",
- "testMethods": [
- "b1",
- "b2"
- ]
- },
- {
- "origin": "TestProjectB-0.0.1",
- "fqn": "CSub1/CSub1",
- "testMethods": [
- "c1",
- "c2"
- ]
- },
- {
- "origin": "TestProjectB-0.0.1",
- "fqn": "CSub2/CSub2",
- "testMethods": [
- "c1",
- "c2",
- "c3"
- ]
- }
- ]
-}</programlisting>
-</section>
-<section xml:id="sec:Test_Session_Example">
-<title>Test Session Example</title>
-<simpara>Below example demonstrates what are the expected HTTP requests and JSON structures for a simple test group.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
-
- @Test
- public void foo() {}
-
- @Test
- @Ignore
- public void bar() {}
-}
-
-class B {
-
- @Test
- public void baz() {}
-}
-
-class C {
-
- @Test
- public void qux() {}
-}</programlisting>
-<programlisting language="json" linenumbering="unnumbered">Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/start/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.start_session_req.tm+json; charset=ISO-8859-1</programlisting>
-<programlisting language="json" linenumbering="unnumbered">Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FC%23qux/start/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.start_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "timeout": 1000
-}
-
-
-Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FB%23baz/start/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.start_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "timeout": 1000
-}
-
-
-Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FA%23bar/start/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.start_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "timeout": 1000
-}
-
-
-Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FA%23foo/start/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.start_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "timeout": 1000
-}</programlisting>
-<programlisting language="json" linenumbering="unnumbered">Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FA%23bar/ping
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.ping_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "timeout": 1000
-}
-
-
-Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FC%23qux/ping/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.ping_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "timeout": 2000
-}</programlisting>
-<programlisting language="json" linenumbering="unnumbered">Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FB%23baz/end/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.end_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "message": "Some optional message.",
- "trace": [
- "trace_element_1",
- "trace_element_2",
- "trace_element_3"
- ],
- "expected": "1",
- "testStatus": "FAILED",
- "elapsedTime": 100,
- "actual": "2"
-}
-
-
-Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FC%23qux/end/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.end_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "message": "Some failure message.",
- "trace": [
- "trace_element_1",
- "trace_element_2",
- "trace_element_3"
- ],
- "expected": "4",
- "testStatus": "FAILED",
- "elapsedTime": 50,
- "actual": "3"
-}
-
-
-Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2F%23foo/end/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.end_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "expected": "2",
- "testStatus": "PASSED",
- "elapsedTime": 60,
- "actual": "power of 2 for 2"
-}
-
-
-Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/tests/Test%2FA%23bar/end/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.end_test_req.tm+json; charset=ISO-8859-1
-Body:
-{
- "testStatus": "SKIPPED",
- "elapsedTime": 0,
-}</programlisting>
-<programlisting language="json" linenumbering="unnumbered">Request method: POST
-Request path: http://localhost:9415/n4js/testing/sessions/19f47a37-c1d1-4cb7-a514-1e131f26ab13/end/
-Headers: Accept=*/*
- Content-Type=application/vnd.n4js.end_session_req.tm+json; charset=ISO-8859-1</programlisting>
-</section>
-</section>
-<section xml:id="sec:Test_Runtime_Configuration">
-<title>Test Runtime Configuration</title>
-<simpara><emphasis>Test Runner</emphasis> must gather relevant information and send it to <emphasis>Test Environment</emphasis> to allow proper test execution:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>gathering user input and test options</simpara>
-</listitem>
-<listitem>
-<simpara>gathering information about user project test code</simpara>
-</listitem>
-<listitem>
-<simpara>maintaining proper name mappings (e.g. if project is minimized test names/references must be mapped correctly)</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Test_Plan">
-<title>Test Plan</title>
-<simpara><emphasis>Test Runner</emphasis> uses N4IDE infrastructure to obtain information about test fragment of the user project. Based on that information and user input in UI (e.g. triggering test execution on whole project) IDE can determine <emphasis>Test Method</emphasis>s that should be executed. Such test list or <emphasis>Test Plan</emphasis> is send to <emphasis>Test Environment</emphasis> and is expected to be executed by a <emphasis>Test Library</emphasis>.</simpara>
-<programlisting language="json" linenumbering="unnumbered">TestPlan {
- Array<TestProcedure> procedures
-}
-
-TestProcedure {
- string functionName,
- string functionType,
- string functionContainer,
- string containerModule
-}</programlisting>
-</section>
-<section xml:id="sec:Test_Environment_Configuration">
-<title>Test Environment Configuration</title>
-<simpara>Additionally <emphasis>Test Runner</emphasis> sends to <emphasis>Test Environment</emphasis> other configuration options:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis>Test Runner</emphasis> test communication protocol base url (<emphasis>baseURL</emphasis>)</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="sec:Test_Environment_Configuration_Example">
-<title>Test Environment Configuration Example</title>
-<simpara>For example assuming that user selects <emphasis>ProjectX</emphasis> to test that contains only one test class in <emphasis>src/test/n4js/core</emphasis> path like:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class MyTestClass{
-
- @BeforeAll
- public void someOneTimeSetup(){ /* setup code */}
-
- @Test
- public void testA(){ /* some test code*/ }
- @Test
- public void testB(){ /* some test code*/ }
- @Test
- public void testC(){ /* some test code*/ }
-
- @After
- public void afterCleanup(){ /* setup code */}
-
-}</programlisting>
-<simpara>Configuration sent for <emphasis>Test Execution Environment</emphasis> would look like:</simpara>
-<programlisting language="json" linenumbering="unnumbered">{
- "baseURL" : "http://localhost:1234/",
- "testPlan":
- [
- {
- "functionName": "someOneTimeSetup",
- "functionType": "@BeforeAll",
- "functionContainer": "MyTestClass",
- "containerModule": "test/n4js/core/MyTestClass",
- },
- {
- "functionName": "testA",
- "functionType": "@Test",
- "functionContainer": "MyTestClassA",
- "containerModule": "test/n4js/core/MyTestClassA",
- },
- {
- "functionName": "afterCleanup",
- "functionType": "@After",
- "functionContainer": "MyTestClassA",
- "containerModule": "test/n4js/core/MyTestClassA",
- },
- {
- "functionName": "testB",
- "functionType": "@Test",
- "functionContainer": "MyTestClassA",
- "containerModule": "test/n4js/core/MyTestClassA",
- },
- {
- "functionName": "afterCleanup",
- "functionType": "@After",
- "functionContainer": "MyTestClassA",
- "containerModule": "test/n4js/core/MyTestClassA",
- },
- {
- "functionName": "testC",
- "functionType": "@Test",
- "functionContainer": "MyTestClassA",
- "containerModule": "test/n4js/core/MyTestClassA",
- },
- {
- "functionName": "afterCleanup",
- "functionType": "@After",
- "functionContainer": "MyTestClassA",
- "containerModule": "test/n4js/core/MyTestClassA",
- }
- ]
-}</programlisting>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_help-system">
-<title>Help System</title>
-<section xml:id="sec:Built_In_Help">
-<title>Built-In Help</title>
-
-</section>
-<section xml:id="sec:Context_Sensitive_Help">
-<title>Context Sensitive Help</title>
-
-</section>
-<section xml:id="sec:Cheat_Sheets">
-<title>Cheat Sheets</title>
-
-</section>
-<section xml:id="sec:JSDoc">
-<title>JSDoc</title>
-
-</section>
-<section xml:id="sec:Hovering">
-<title>Hovering</title>
-<simpara>Hovering over an element (such as type, field, method, function or variable declaration) in the N4JS editor will cause a tooltip appear containing information about the underlying element. Currently this information is the type (could be the inferred type as well), the name and the keyword (such as class, variable, field) of the actual element. By default the tooltip does not grab the focus from the currently active workbench window and will automatically disappear after the focus is lost from the element. One can grab the focus for the tooltip by clicking into the tooltip area or pressing <keycap>F2</keycap> function key.</simpara>
-<section xml:id="sec:Show_Type_Information_of_Selection">
-<title>Show Type Information of Selection</title>
-<simpara>In some cases, during the development process, one would like to know what is the actual or even the inferred type of an N4JS expression. To use this functionality one can select the desired expression in the editor and invoke the ’Show Type Information’ command via the <keycap>Cmd</keycap> + <keycap>Option</keycap>+ <keycap>I</keycap> ( <keycap>Ctrl</keycap> + <keycap>Alt</keycap>+ <keycap>I</keycap> Windows/Linux) from the keyboard. This case a popup window will be raised containing the type information of the actual selection.</simpara>
-</section>
-</section>
-<section xml:id="sec:Example_Projects_and_Files">
-<title>Example Projects and Files</title>
-
-</section>
-</chapter>
-<chapter xml:id="_bug-management">
-<title>Bug Management</title>
-<warning>
-<simpara>Parts of this document may be outdated.</simpara>
-</warning>
-<section xml:id="sec:Built_In_Xpect_Support">
-<title>Built-In Xpect Support</title>
-<simpara>N4IDE contains built-in support for <link xl:href="http://www.xpect-tests.org/">xpect</link> based tests. The purpose of those is to create tests for N4IDE support for user code, not the user code itself. Users can create <emphasis>fileName.n4js.xt</emphasis> to write their test for a given N4IDE functionality. Those files can be executed (via context menu, run configurations, etc.) to verify user expectations.</simpara>
-<section xml:id="sec:Report_View">
-<title>Report View</title>
-<simpara>When executing xpect tests, users can view the results in a special view available in the IDE: <keycap>Window</keycap> → <keycap>Show View</keycap> → <keycap>Other</keycap> → <keycap>Test Views</keycap> → <keycap>Xpect View</keycap>.</simpara>
-<figure xml:id="fig:test_view" role="center">
-<title>Test View</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_bugmanagement/fig/testView.png" width="75%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>testView</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>This view allows user to generate bug report (see <link linkend="sec:Generate_Bug_Report">Generating Bug Reports</link>).</simpara>
-<simpara>In case of failing tests, users can see additional information (e.g. a stacktrace), or call a comparison view.</simpara>
-<figure xml:id="fig:comparison" role="center">
-<title>Comparison</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_bugmanagement/fig/comparison.png" width="75%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>comparison</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:Generate_Bug_Report">
-<title>Generate Bug Report</title>
-<simpara>Generating bug reports can be done when there is some <literal>.n4js.xt</literal> file with all passing expectations, and at least one of them marked with <emphasis>FIXME</emphasis>. In this case icon of the executed test suite changes and via context menu user can call generate bug report option. When it is done, user can see contents of the bug generated in the console view. This output is prepared for out JIRA ticketing system.</simpara>
-<figure xml:id="fig:bug_report" role="center">
-<title>Bug Report</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_bugmanagement/fig/bugReport.png" width="75%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>bugReport</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>There is also possibility to generate bug report via file selection and context menu. In this case xpect test is not executed, only bug contents are generated.</simpara>
-<figure xml:id="fig:bug" role="center">
-<title>Submited Bug</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_bugmanagement/fig/bug.png" width="50%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>bug</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-<section xml:id="sec:Supported_Xpect_Tests">
-<title>Supported Xpect Tests</title>
-<simpara>Xpect methods are special form of comments inside <emphasis>.xt</emphasis> files. General syntax for declaring usage of such method is <emphasis>XPECT</emphasis> marker followed by <emphasis>XpectMethodName</emphasis> and parameters for that method, all placed in comment. This can have three forms:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Single line comment (see the first comment in the listing below), Notice <emphasis role="strong"><literal>→</literal></emphasis> separating the method name and its parameters.</simpara>
-</listitem>
-<listitem>
-<simpara>Multi line comment with one method invocation, notice <emphasis role="strong"><literal>-</literal></emphasis> separating the method name and its parameters</simpara>
-</listitem>
-<listitem>
-<simpara>Multi line comment with multiple method invocations, simmilar to one above, but each line of method parameters indicates separate method invocation</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">//XPECT errors --> "Couldn't resolve reference to IdentifiableElement 'consoleX'." at "consoleX"
-consoleX.log(10);
-
-/*XPECT errors ---
- "Couldn't resolve reference to IdentifiableElement 'logY'." at "logY"
----*/
-console.logY(10);
-
-/*XPECT errors ---
- "Couldn't resolve reference to IdentifiableElement 'log'." at "log"
- "Couldn't resolve reference to IdentifiableElement 'ref'." at "ref"
- --- */
-log(ref);</programlisting>
-</listitem>
-</itemizedlist>
-<section xml:id="sec:XPECT_N4JS_Errors">
-<title>Errors, Warnings, Infos, Issues</title>
-<simpara><emphasis>Errors</emphasis>, <emphasis>Warnings</emphasis>, <emphasis>Infos</emphasis> are xpect methods that allow to capture marker of given severity. Additionally <emphasis>Issues</emphasis> allows to allow markers of all above severities.</simpara>
-<simpara>All of those methods can be used single invocations or as mutline invocations.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">//XPECT errors --> "Couldn't resolve reference to IdentifiableElement 'x'." at "x"
-console.log(x)
-
-//XPECT warnings --> "Variable names should start with lower case letter." at "String"
-var String = "some string"</programlisting>
-</section>
-<section xml:id="sec:XPECT_N4JS_Noerrors">
-<title>Noerrors</title>
-<simpara>No errors allows to catch (and suppress) marker of any severity (<emphasis>error</emphasis>, <emphasis>warning</emphasis>, <emphasis>info</emphasis>).</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">//XPECT noerrors --> "window object should be recognized"
-console.log(window)</programlisting>
-</section>
-<section xml:id="sec:XPECT_N4JS_Output">
-<title>Output, OutputRegex</title>
-<simpara>Output methods are special in sense that they are not intended to be used on single element of the script, but they apply to the whole script.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/* XPECT output ---
-<==
-stdout:
-hello world
-stderr:
-==>
---- */
-console.log("hello world")</programlisting>
-<simpara>Second method accepts regex expressions. This allows to deal with troublesome output (e.g. dates)</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/* XPECT outputRegex ---
-<==
-stdout:
-[^\n]*
-stderr:
-==>
---- */
-console.log(new Date())</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">/* XPECT outputRegex ---
-<==
-stdout:
-hello world
-stderr:
-
-[^\n]+
-throw ' cruel world'
-\^
- cruel world
-==>
---- */
-console.log("hello world")
-throw ' cruel world'</programlisting>
-</section>
-<section xml:id="sec:XPECT_N4JS_Type_Of">
-<title>Type Of</title>
-<simpara>Xpect type methods allow test type inference, both for inferred type or expected type.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">//XPECT type of 'probablySomeString' --> string
-var probablySomeString = "some string";
-
-var union{string,number} u;
-// XPECT expectedType at 'null' --> {function(number?):string}
-u.toString = null</programlisting>
-</section>
-<section xml:id="sec:XPECT_Advanced_Methods">
-<title>Advanced methods</title>
-<simpara>There are also other methods provided, that allow to test quick fixes and content assist. Their parameters syntax is more complicated. Additionally they actively modify contents of the editor, or even close it if needed. Their usage exceeds scope of this document.</simpara>
-</section>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_cli">
-<title>CLI</title>
-<warning>
-<simpara>Parts of this document may be outdated.</simpara>
-</warning>
-<section xml:id="sec:Headless_Compiler" role="language-bash">
-<title>Headless Compiler</title>
-<simpara>The headless compiler is provided as a separate tool, coming as a single jar file <literal>n4jsc.jar</literal>. It is to be invoked via</simpara>
-<programlisting language="bash" linenumbering="unnumbered">java -jar n4jsc.jar</programlisting>
-<simpara>Simply invoking the headless compiler with no further arguments will print out a description of command line options.</simpara>
-<simpara>The headless compiler works in three major modes (given as arguments to the switch <literal>-bt</literal>):</simpara>
-<itemizedlist>
-<listitem>
-<simpara>compilation of single files (<literal>-bt singlefile</literal>, <emphasis>default</emphasis>),</simpara>
-</listitem>
-<listitem>
-<simpara>compilation of given projects (<literal>-bt projects</literal>) or</simpara>
-</listitem>
-<listitem>
-<simpara>compilation of all projects (<literal>-bt allprojects</literal>)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The command-line invocation usually has the form of</simpara>
-<programlisting language="bash" linenumbering="unnumbered">java -jar n4jsc.jar ^$[options]$^ file1 file2 ...</programlisting>
-<simpara>Standard compiler <emphasis>options</emphasis>:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--buildType</literal> , <literal>-bt</literal> <emphasis>mode</emphasis></term>
-<listitem>
-<simpara>With <emphasis>mode</emphasis> as exactly one of</simpara>
-<variablelist>
-<varlistentry>
-<term>singlefile</term>
-<listitem>
-<simpara>only the source files given by <emphasis>file1</emphasis>, <emphasis>file2</emphasis>, …​ are compiled.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>projects</term>
-<listitem>
-<simpara><emphasis>file1</emphasis>, <emphasis>file2</emphasis>, …​ denote projects (folders containing a <literal>manifest.n4mf</literal>). These projects will be compiled.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>allprojects</term>
-<listitem>
-<simpara>All project found under the project-root(s) are compiled. There should be no <emphasis>file…​</emphasis> given.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>dontcompile</term>
-<listitem>
-<simpara>Nothing will be compiled. There should be no <emphasis>file…​</emphasis> given. (This is the default if no <literal>-t</literal> option is given).</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--projectlocations</literal> (<literal>-pl</literal>) <literal>path</literal></term>
-<listitem>
-<simpara><anchor xml:id="opt-projectlocations" xreflabel="[opt-projectlocations]"/> provide folder(s) to search for projects. If not set, the base folder of the running JVM will be taken as the location. Multiple folders are separated by the systems path-separator (’<literal>:</literal>’ on Mac / Unix and ’<literal>;</literal>’ on Windows). Only direct subfolders will be queried for projects. A subfolder is assumed to be a N4JS-project if it contains a <literal>manifest.n4mf</literal> file. All found projects are taken into consideration for dependency-resolution. Example on Linux:<?asciidoc-br?>
- <literal>-pl /rootA/: /rootB:/some/absolute/path/to/projects</literal>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Advanced compiler options (optional):</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--notests</literal></term>
-<listitem>
-<simpara>turn off compilation of code in test-folders. Can not be combined with <literal>–testonly</literal></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--testonly</literal></term>
-<listitem>
-<simpara>only compile test code. Externals and sources will not be compiled. Can not be combined with <literal>–notests</literal></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--keepCompiling</literal></term>
-<listitem>
-<simpara>try to compile even if some errors occur.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--preference</literal> <emphasis>file</emphasis></term>
-<listitem>
-<simpara>uses <emphasis>file</emphasis> as there internal preferences-store similar to the preferences internally stored by the N4IDE.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Additional command line options (optional):</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--help</literal> , <literal>-h</literal> </term>
-<listitem>
-<simpara>prints out help to the console and exits.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--verbose</literal> , <literal>-v</literal></term>
-<listitem>
-<simpara>verbose output during build</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--debug</literal> </term>
-<listitem>
-<simpara>before executing, summarises the information of the current setup like resolved pathnames and other information, carries on with normal workflow and prints additional status information about loading and unloading projects and processing each resource.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--log</literal></term>
-<listitem>
-<simpara>write a log file <literal>n4jsc.log</literal> to the base folder. (Change filename with <literal>–logfile filename</literal>)</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="sec:Headless_Dependencies" role="language-bash">
-<title>Headless Dependnecies</title>
-<simpara>Compiler can manage dependencies of the processed projects:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--installMissingDependencies</literal> , <literal>-imd</literal> </term>
-<listitem>
-<simpara>alnalyzes available projects and installs missing dependencies</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--targetPlatformInstallLocation</literal> , <literal>-tl</literal></term>
-<listitem>
-<simpara>location to which dependencies will be installed, if not provided temporal location will be used</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--npmrcRootLocation</literal></term>
-<listitem>
-<simpara>location of the <emphasis>.npmrc</emphasis> file to be used in <emphasis>npm</emphasis> invocations</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="sec:Headless_Execution" role="language-bash">
-<title>Headless Execution</title>
-<simpara>For headless compiling, running and testing of N4JS code a general command line tool is provided. Many parameters of the different use cases are shared. Although you can combine the use cases each of them is described in its own section. This section is about running compiled code.</simpara>
-<simpara>For compiling refer to <link linkend="sec:Headless_Compiler">Headless Compiler</link> for executing tests refer to <link linkend="_test_support">Tests</link>.</simpara>
-<section xml:id="sec:Cleaning_Headlessly">
-<title>Cleaning Headlessly</title>
-<simpara>It is possible to use the headless compiler to clean projects by using the following option</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--clean</literal> (<literal>-c</literal>)</term>
-<listitem>
-<simpara>When this option is used. The headless compiler only cleans projects without compilation. Moreover, the use of this option requires that the option <literal>-t</literal> must be specified and must be either <literal>-t projects</literal> or <literal>-t allprojects</literal>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>For instance, <literal>n4jsc --clean -t allprojects -pl path/to/project</literal> or <literal>n4jsc --clean -t projects project1 project2</literal> are valid use while <literal>n4jsc --clean -t singlefile file1 file2</literal> is invalid.
-After the calling the command with <literal>--clean (</literal>-c`), the output folders of the specified projects (e.g. <literal>src-gen</literal> folders) are cleaned.</simpara>
-</section>
-<section xml:id="sec:Running_Headlessly">
-<title>Running Headlessly</title>
-<simpara>Running code from the command line requires basically three different pieces of information:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The locations where projects, libraries and environments can be found must be given.</simpara>
-</listitem>
-<listitem>
-<simpara>The starting point of execution must be given by pointing to a module.</simpara>
-</listitem>
-<listitem>
-<simpara>Since there are multiple different project types, an adequate Runner has to be selected.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The follwing command line switches are used to provide this information:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--projectlocations</literal> (<literal>-pl</literal>) <literal>path</literal></term>
-<listitem>
-<simpara>path of locations to search for projects (c.f. <link linkend="sec:Headless_Compiler">Headless Compiler</link> ,<link linkend="opt-projectlocations">Project Locations</link>)</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--runWith</literal> (<literal>-rw</literal>) <literal>VAL</literal></term>
-<listitem>
-<simpara>denotes the runner-id (as listed with --list-runners) or at least the last segment of it</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--run</literal> (<literal>-r</literal>) <literal>FILE</literal></term>
-<listitem>
-<simpara>source-module to run. Note you should point to the full location of the source file (*.n4js). The runner is <emphasis>responsible to determine the compiled file</emphasis>. It is not sufficient to give a project-relative path, it always needs to be a full path to the source file.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>It is possible to compile and run with a single CLI line. Compilation always precedes the execution. It the compilation fails the runner will not be started.</simpara>
-<simpara>To ease the usage of different runners it is allowed to provide the last segment(s) of the runner-id in a case-insensitive way, e.g. one can use the runner with id <literal>org.eclipse.n4js.runner.nodejs.NODEJS</literal> as follows:</simpara>
-<programlisting language="bash" linenumbering="unnumbered">.. --runWith org.eclipse.n4js.runner.nodejs.NODEJS ..</programlisting>
-<simpara>or in short</simpara>
-<programlisting language="bash" linenumbering="unnumbered">.. --rw NODEJS ..</programlisting>
-<simpara>or even lower-cased with</simpara>
-<programlisting language="bash" linenumbering="unnumbered">.. --rw nodejs ..</programlisting>
-<simpara>Assume having a common workspace location ’wsp’ with a project ’P1’ containing the module ’A’. The following line shows how to run this code:</simpara>
-<programlisting language="bash" linenumbering="unnumbered">java -jar n4jsc.jar -pl wsp -rw nodejs -r wsp/P1/src/A.n4js</programlisting>
-</section>
-<section xml:id="sec:Information_about_running_headlessly">
-<title>Information about running headlessly</title>
-<simpara>Available runner-ids can be actively queried:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--listRunners</literal> (<literal>-lr</literal>)</term>
-<listitem>
-<simpara>prints out a list of all available command-line runners</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="sec:Testing_Headlessly">
-<title>Testing Headlessly</title>
-<simpara>Testing code from the command line requires basically three different pieces of information:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The locations where projects, libraries and environments can be found must be given.</simpara>
-</listitem>
-<listitem>
-<simpara>The starting point of test execution must be given by pointing to what is supposed to be tested (single file / whole project)/</simpara>
-</listitem>
-<listitem>
-<simpara>Since there are multiple different project types, an adequate Tester has to be selected.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The follwing command line switches are used to provide this information:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--projectlocations</literal> (<literal>-pl</literal>) <literal>path</literal></term>
-<listitem>
-<simpara>path of locations to search for projects (c.f. <link linkend="sec:Headless_Compiler">Headless Compiler</link> ,<link linkend="opt-projectlocations">Project Locations</link>)</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--testWith</literal> (<literal>-tw</literal>) <literal>VAL</literal></term>
-<listitem>
-<simpara>denotes the tester-id (as listed with --list-testers) or at least the last segment of it</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>--test</literal> (<literal>-t</literal>) <literal>FILE</literal></term>
-<listitem>
-<simpara>source-module to run. Note you should point to the full location of the project with tests, specific folder inside project with tests or the test source file (*.n4js). It is not sufficient to give a project-relative path, it always needs to be a full path to the source file.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>It is possible to compile and run with a single CLI line. Compilation always precedes the execution. It the compilation fails the tester will not be started.</simpara>
-<simpara>To ease the usage of different testers it is allowed to provide the last segment(s) of the tester-id in a case-insensitive way, e.g. one can use the runner with id <literal>org.eclipse.n4js.tester.nodejs.NODEJS_MANGELHAFT</literal> as follows:</simpara>
-<programlisting language="bash" linenumbering="unnumbered">.. --runWith org.eclipse.n4js.tester.nodejs.NODEJS_MANGELHAFT ..</programlisting>
-<simpara>or in short</simpara>
-<programlisting language="bash" linenumbering="unnumbered">.. --rw NODEJS_MANGELHAFT ..</programlisting>
-<simpara>or even lower-cased with</simpara>
-<programlisting language="bash" linenumbering="unnumbered">.. --rw nodejs_mangelhaft ..</programlisting>
-<simpara>Assume having a common workspace location ’wsp’ with a project ’P1’ containing the module ’TestA’. The following line shows how to execute this test code:</simpara>
-<programlisting language="bash" linenumbering="unnumbered">java -jar n4jsc.jar -pl wsp -tw nodejs_mangelhaft -t wsp/P1/src/TestA.n4js</programlisting>
-</section>
-<section xml:id="sec:Information_about_testing_headlessly">
-<title>Information about testing headlessly</title>
-<simpara>Available tester-ids can be actively queried:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>--listTesters</literal> (<literal>-lt</literal>)</term>
-<listitem>
-<simpara>prints out a list of all available command-line testers</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_testresults">
-<title>TestResults</title>
-<simpara>TODO</simpara>
-<simpara><?asciidoc-pagebreak?></simpara>
-</section>
-</section>
-</chapter>
-<appendix xml:id="sec:License">
-<title>License</title>
-<simpara>This specification and the accompanying materials is made available
-under the terms of the Eclipse Public License v1.0 which accompanies
-this distribution, and is available at <link xl:href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</link></simpara>
-<bridgehead xml:id="_eclipse-public-license-v-1-0" renderas="sect2">Eclipse Public License - v 1.0</bridgehead>
-<simpara>THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE
-PUBLIC LICENSE (<literal>AGREEMENT</literal>). ANY USE, REPRODUCTION OR DISTRIBUTION OF
-THE PROGRAM CONSTITUTES RECIPIENT’S ACCEPTANCE OF THIS AGREEMENT.</simpara>
-<bridgehead xml:id="_1-definitions" renderas="sect3">1. DEFINITIONS</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>Contribution</literal> means: </term>
-<listitem>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>in the case of the initial Contributor, the initial code and
-documentation distributed under this Agreement, and</simpara>
-</listitem>
-<listitem>
-<simpara>in the case of each subsequent Contributor:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>changes to the Program, and</simpara>
-</listitem>
-<listitem>
-<simpara>additions to the Program;</simpara>
-<simpara>where such changes and/or additions to the Program originate from and
-are distributed by that particular Contributor. A Contribution
-’originates’ from a Contributor if it was added to the Program by such
-Contributor itself or anyone acting on such Contributor’s behalf.
-Contributions do not include additions to the Program which:</simpara>
-<orderedlist numeration="lowerroman">
-<listitem>
-<simpara>are separate modules of software distributed in conjunction with the Program
-under their own license agreement, and</simpara>
-</listitem>
-<listitem>
-<simpara>are not derivative works of the Program.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Contributor</literal></term>
-<listitem>
-<simpara>means any person or entity that distributes the Program.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Licensed Patents</literal> </term>
-<listitem>
-<simpara>mean patent claims licensable by a Contributor
-which are necessarily infringed by the use or sale of its Contribution
-alone or when combined with the Program.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Program</literal> </term>
-<listitem>
-<simpara>means the Contributions distributed in accordance with this
-Agreement.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Recipient</literal> </term>
-<listitem>
-<simpara>means anyone who receives the Program under this
-Agreement, including all Contributors.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="_2-grant-of-rights" renderas="sect3">2. GRANT OF RIGHTS</bridgehead>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Subject to the terms of this Agreement, each Contributor hereby
-grants Recipient a non-exclusive, worldwide, royalty-free copyright
-license to reproduce, prepare derivative works of, publicly display,
-publicly perform, distribute and sublicense the Contribution of such
-Contributor, if any, and such derivative works, in source code and
-object code form.</simpara>
-</listitem>
-<listitem>
-<simpara>Subject to the terms of this Agreement, each Contributor hereby
-grants Recipient a non-exclusive, worldwide, royalty-free patent license
-under Licensed Patents to make, use, sell, offer to sell, import and
-otherwise transfer the Contribution of such Contributor, if any, in
-source code and object code form. This patent license shall apply to the
-combination of the Contribution and the Program if, at the time the
-Contribution is added by the Contributor, such addition of the
-Contribution causes such combination to be covered by the Licensed
-Patents. The patent license shall not apply to any other combinations
-which include the Contribution. No hardware per se is licensed
-hereunder.</simpara>
-</listitem>
-<listitem>
-<simpara>Recipient understands that although each Contributor grants the
-licenses to its Contributions set forth herein, no assurances are
-provided by any Contributor that the Program does not infringe the
-patent or other intellectual property rights of any other entity. Each
-Contributor disclaims any liability to Recipient for claims brought by
-any other entity based on infringement of intellectual property rights
-or otherwise. As a condition to exercising the rights and licenses
-granted hereunder, each Recipient hereby assumes sole responsibility to
-secure any other intellectual property rights needed, if any. For
-example, if a third party patent license is required to allow Recipient
-to distribute the Program, it is Recipient’s responsibility to acquire
-that license before distributing the Program.</simpara>
-</listitem>
-<listitem>
-<simpara>Each Contributor represents that to its knowledge it has sufficient
-copyright rights in its Contribution, if any, to grant the copyright
-license set forth in this Agreement.</simpara>
-</listitem>
-</orderedlist>
-<bridgehead xml:id="_3-requirements" renderas="sect3">3. REQUIREMENTS</bridgehead>
-<simpara>A Contributor may choose to distribute the Program in object code form
-under its own license agreement, provided that:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>it complies with the terms and conditions of this Agreement; and</simpara>
-</listitem>
-<listitem>
-<simpara>its license agreement:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>effectively disclaims on behalf of all Contributors all warranties
-and conditions, express and implied, including warranties or conditions
-of title and non-infringement, and implied warranties or conditions of
-merchantability and fitness for a particular purpose;</simpara>
-</listitem>
-<listitem>
-<simpara>effectively excludes on behalf of all Contributors all liability for
-damages, including direct, indirect, special, incidental and
-consequential damages, such as lost profits;</simpara>
-</listitem>
-<listitem>
-<simpara>states that any provisions which differ from this Agreement are
-offered by that Contributor alone and not by any other party; and</simpara>
-</listitem>
-<listitem>
-<simpara>states that source code for the Program is available from such
-Contributor, and informs licensees how to obtain it in a reasonable
-manner on or through a medium customarily used for software exchange.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-<simpara>When the Program is made available in source code form:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>it must be made available under this Agreement; and</simpara>
-</listitem>
-<listitem>
-<simpara>a copy of this Agreement must be included with each copy of the
-Program.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Contributors may not remove or alter any copyright notices contained
-within the Program.</simpara>
-<simpara>Each Contributor must identify itself as the originator of its
-Contribution, if any, in a manner that reasonably allows subsequent
-Recipients to identify the originator of the Contribution.</simpara>
-<bridgehead xml:id="_4-commercial-distribution" renderas="sect3">4. COMMERCIAL DISTRIBUTION</bridgehead>
-<simpara>Commercial distributors of software may accept certain responsibilities
-with respect to end users, business partners and the like. While this
-license is intended to facilitate the commercial use of the Program, the
-Contributor who includes the Program in a commercial product offering
-should do so in a manner which does not create potential liability for
-other Contributors. Therefore, if a Contributor includes the Program in
-a commercial product offering, such Contributor (<literal>Commercial
-Contributor</literal>) hereby agrees to defend and indemnify every other
-Contributor (<literal>Indemnified Contributor</literal>) against any losses, damages
-and costs (collectively <literal>Losses</literal>) arising from claims, lawsuits and
-other legal actions brought by a third party against the Indemnified
-Contributor to the extent caused by the acts or omissions of such
-Commercial Contributor in connection with its distribution of the
-Program in a commercial product offering. The obligations in this
-section do not apply to any claims or Losses relating to any actual or
-alleged intellectual property infringement. In order to qualify, an
-Indemnified Contributor must: a) promptly notify the Commercial
-Contributor in writing of such claim, and b) allow the Commercial
-Contributor to control, and cooperate with the Commercial Contributor
-in, the defense and any related settlement negotiations. The Indemnified
-Contributor may participate in any such claim at its own expense.</simpara>
-<simpara>For example, a Contributor might include the Program in a commercial
-product offering, Product X. That Contributor is then a Commercial
-Contributor. If that Commercial Contributor then makes performance
-claims, or offers warranties related to Product X, those performance
-claims and warranties are such Commercial Contributor’s responsibility
-alone. Under this section, the Commercial Contributor would have to
-defend claims against the other Contributors related to those
-performance claims and warranties, and if a court requires any other
-Contributor to pay any damages as a result, the Commercial Contributor
-must pay those damages.</simpara>
-<bridgehead xml:id="_5-no-warranty" renderas="sect3">5. NO WARRANTY</bridgehead>
-<simpara>EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED
-ON AN <literal>AS IS</literal> BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
-EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES
-OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR
-A PARTICULAR PURPOSE. Each Recipient is solely responsible for
-determining the appropriateness of using and distributing the Program
-and assumes all risks associated with its exercise of rights under this
-Agreement , including but not limited to the risks and costs of program
-errors, compliance with applicable laws, damage to or loss of data,
-programs or equipment, and unavailability or interruption of operations.</simpara>
-<bridgehead xml:id="_6-disclaimer-of-liability" renderas="sect3">6. DISCLAIMER OF LIABILITY</bridgehead>
-<simpara>EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR
-ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT,
-INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING
-WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF
-LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
-NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR
-DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
-HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</simpara>
-<bridgehead xml:id="_7-general" renderas="sect3">7. GENERAL</bridgehead>
-<simpara>If any provision of this Agreement is invalid or unenforceable under
-applicable law, it shall not affect the validity or enforceability of
-the remainder of the terms of this Agreement, and without further action
-by the parties hereto, such provision shall be reformed to the minimum
-extent necessary to make such provision valid and enforceable.</simpara>
-<simpara>If Recipient institutes patent litigation against any entity (including
-a cross-claim or counterclaim in a lawsuit) alleging that the Program
-itself (excluding combinations of the Program with other software or
-hardware) infringes such Recipient’s patent(s), then such Recipient’s
-rights granted under Section 2(b) shall terminate as of the date such
-litigation is filed.</simpara>
-<simpara>All Recipient’s rights under this Agreement shall terminate if it fails
-to comply with any of the material terms or conditions of this Agreement
-and does not cure such failure in a reasonable period of time after
-becoming aware of such noncompliance. If all Recipient’s rights under
-this Agreement terminate, Recipient agrees to cease use and distribution
-of the Program as soon as reasonably practicable. However, Recipient’s
-obligations under this Agreement and any licenses granted by Recipient
-relating to the Program shall continue and survive.</simpara>
-<simpara>Everyone is permitted to copy and distribute copies of this Agreement,
-but in order to avoid inconsistency the Agreement is copyrighted and may
-only be modified in the following manner. The Agreement Steward reserves
-the right to publish new versions (including revisions) of this
-Agreement from time to time. No one other than the Agreement Steward has
-the right to modify this Agreement. The Eclipse Foundation is the
-initial Agreement Steward. The Eclipse Foundation may assign the
-responsibility to serve as the Agreement Steward to a suitable separate
-entity. Each new version of the Agreement will be given a distinguishing
-version number. The Program (including Contributions) may always be
-distributed subject to the version of the Agreement under which it was
-received. In addition, after a new version of the Agreement is
-published, Contributor may elect to distribute the Program (including
-its Contributions) under the new version. Except as expressly stated in
-Sections 2(a) and 2(b) above, Recipient receives no rights or licenses
-to the intellectual property of any Contributor under this Agreement,
-whether expressly, by implication, estoppel or otherwise. All rights in
-the Program not expressly granted under this Agreement are reserved.</simpara>
-<simpara>This Agreement is governed by the laws of the State of New York and the
-intellectual property laws of the United States of America. No party to
-this Agreement will bring a legal action under this Agreement more than
-one year after the cause of action arose. Each party waives its rights
-to a jury trial in any resulting litigation.</simpara>
-</appendix>
-<appendix xml:id="sec:Acronyms">
-<title>Acronyms</title>
-<informaltable xml:id="AC" role="language-bash" frame="all" rowsep="1" colsep="1">
-<tgroup cols="4">
-<colspec colname="col_1" colwidth="8.3333*"/>
-<colspec colname="col_2" colwidth="41.6666*"/>
-<colspec colname="col_3" colwidth="8.3333*"/>
-<colspec colname="col_4" colwidth="41.6668*"/>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><literal>CDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Compile-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>RDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Run-Time Dependency</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>LDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Load-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>IDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Initialization-Time Dependency</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>EDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Execution-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>ANTLR</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">ANother Tool for Language Recognition</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>API</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Application Programming Interface</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>AST</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Abstract Syntax Tree</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>ASI</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Automatic Semicolon Insertion</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>BNF</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Backus-Naur Form</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>CLI</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Command Line Interface (including a headless compiler and runner.)</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>DI</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Dependency Injection</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>DIC</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">DI Component</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>DOM</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Document Object Model</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>DSL</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Domain Specific Language</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>EBNF</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Extended Backus-Naur Form</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>EMF</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Eclipse Modeling Framework <anchor xml:id="EMF" xreflabel="[EMF]"/></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>FQN</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Fully Qualified Name</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>GLB</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Greatest Lower Bound, also known as <emphasis>infimum</emphasis></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>GCST</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Greatest Common Sub Type, also known as <emphasis>meet</emphasis></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>IDE</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Integrated Development Environment</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>IDL</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Interface Definition Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>LSP</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Liskov Substitution Principle [<link linkend="Martin96b">Martin96b</link>]</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>LUB</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Least Upper Bound, also known as <emphasis>supremum</emphasis></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>LCST</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Least Common Super Type, also known as <emphasis>join</emphasis></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>N4JS</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4JS for JavaScript</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>N4JSED</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4JS Environment Definition</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>N4JSIDE</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4JS Integrated Development Environment (Eclipse-based IDE for all N4JS related languages and projects)</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>VM</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Virtual Machine</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>XML</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Extensible Markup Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>XSLT / XSL</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">XSL Transformations</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>XSL</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Extensible Stylesheet Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>WYSIWYG</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">What You See Is What You Get</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>WLOG</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Without loss of generality</emphasis></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</appendix>
-<appendix xml:id="_bibliography">
-<title>Bibliography</title>
-<simpara><anchor xml:id="N4JSSpec" xreflabel="[N4JSSpec]"/><emphasis>N4JS Language Specification</emphasis>. </simpara>
-<simpara><anchor xml:id="Martin96b" xreflabel="[Martin96b]"/>Martin, Robert C. (1996). <emphasis>The Liskov Substitution Principle</emphasis>. Retrieved from <link xl:href="http://www.objectmentor.com/publications/lsp.pdf">http://www.objectmentor.com/publications/lsp.pdf</link></simpara>
-</appendix>
-</book>
\ No newline at end of file
diff --git a/idespec/appendix_a_license.html b/idespec/appendix_a_license.html
index cfd8d07..5b661a7 100644
--- a/idespec/appendix_a_license.html
+++ b/idespec/appendix_a_license.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -592,7 +592,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/appendix_b_acronyms.html b/idespec/appendix_b_acronyms.html
index 70ee999..fedfbcf 100644
--- a/idespec/appendix_b_acronyms.html
+++ b/idespec/appendix_b_acronyms.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -406,7 +406,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/appendix_c_bibliography.html b/idespec/appendix_c_bibliography.html
index 5547f3a..1430bfb 100644
--- a/idespec/appendix_c_bibliography.html
+++ b/idespec/appendix_c_bibliography.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -304,7 +304,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/assistance.html b/idespec/assistance.html
index d6bec19..c765d42 100644
--- a/idespec/assistance.html
+++ b/idespec/assistance.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1536,7 +1536,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/bug_management.html b/idespec/bug_management.html
index c06f8da..95fc090 100644
--- a/idespec/bug_management.html
+++ b/idespec/bug_management.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -496,7 +496,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/cli.html b/idespec/cli.html
index 113b0dc..7065dc4 100644
--- a/idespec/cli.html
+++ b/idespec/cli.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -655,7 +655,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/execution_support.html b/idespec/execution_support.html
index 47ef512..5ddbabd 100644
--- a/idespec/execution_support.html
+++ b/idespec/execution_support.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -368,7 +368,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/help_system.html b/idespec/help_system.html
index 71095c3..4a8f29b 100644
--- a/idespec/help_system.html
+++ b/idespec/help_system.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -326,7 +326,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/index.html b/idespec/index.html
index 19b089f..b7768fa 100644
--- a/idespec/index.html
+++ b/idespec/index.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -289,7 +289,7 @@
<div id="preamble">
<div class="sectionbody">
<div class="paragraph center">
-<p><strong>Last Updated: 2019-08-07</strong></p>
+<p><strong>Last Updated: 2019-08-08</strong></p>
</div>
<div class="paragraph center">
<p><strong>Authors:</strong><br>
@@ -336,7 +336,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/navigation.html b/idespec/navigation.html
index 12f4629..e97a891 100644
--- a/idespec/navigation.html
+++ b/idespec/navigation.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -723,7 +723,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/test_support.html b/idespec/test_support.html
index b6e1e18..73a30a8 100644
--- a/idespec/test_support.html
+++ b/idespec/test_support.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1884,7 +1884,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/views.html b/idespec/views.html
index 04aa1c5..7c72ca5 100644
--- a/idespec/views.html
+++ b/idespec/views.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -381,7 +381,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/idespec/wizards.html b/idespec/wizards.html
index 7749005..f918987 100644
--- a/idespec/wizards.html
+++ b/idespec/wizards.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS IDE Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS IDE Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -477,7 +477,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Project constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413a"></a><strong>Req. GH-1413a:</strong> <a href="#Req-GH-1413a">Project constraints</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -505,7 +505,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Project browse button</a> (ver. 1)</p>
+<p><a id="Req-GH-1413b"></a><strong>Req. GH-1413b:</strong> <a href="#Req-GH-1413b">Project browse button</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -520,7 +520,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Project initial selection inference</a> (ver. 1)</p>
+<p><a id="Req-GH-1413c"></a><strong>Req. GH-1413c:</strong> <a href="#Req-GH-1413c">Project initial selection inference</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -535,7 +535,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Project content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413d"></a><strong>Req. GH-1413d:</strong> <a href="#Req-GH-1413d">Project content assist</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -558,7 +558,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Source folder constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413e"></a><strong>Req. GH-1413e:</strong> <a href="#Req-GH-1413e">Source folder constraints</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -594,7 +594,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Source folder browse button</a> (ver. 1)</p>
+<p><a id="Req-GH-1413f"></a><strong>Req. GH-1413f:</strong> <a href="#Req-GH-1413f">Source folder browse button</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -609,7 +609,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Source folder initial selection inference</a> (ver. 1)</p>
+<p><a id="Req-GH-1413g"></a><strong>Req. GH-1413g:</strong> <a href="#Req-GH-1413g">Source folder initial selection inference</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -624,7 +624,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Source folder content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413h"></a><strong>Req. GH-1413h:</strong> <a href="#Req-GH-1413h">Source folder content assist</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -647,7 +647,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413i"></a><strong>Req. GH-1413i:</strong> <a href="#Req-GH-1413i">Module specifier constraints</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>The specifier is a valid module specifier that is
@@ -659,7 +659,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier completion</a> (ver. 1)</p>
+<p><a id="Req-GH-1413j"></a><strong>Req. GH-1413j:</strong> <a href="#Req-GH-1413j">Module specifier completion</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Manually inserting a specifier ending with a separator is valid.
@@ -670,7 +670,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier grey suffix</a> (ver. 1)</p>
+<p><a id="Req-GH-1413k"></a><strong>Req. GH-1413k:</strong> <a href="#Req-GH-1413k">Module specifier grey suffix</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>A grey suffix should suggest the attached class name as module name if the specifier only specifies a base path.</p>
@@ -680,7 +680,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier browse button</a> (ver. 1)</p>
+<p><a id="Req-GH-1413l"></a><strong>Req. GH-1413l:</strong> <a href="#Req-GH-1413l">Module specifier browse button</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Browsing only allows the selection of modules or module containers in the selected source folder. The browse dialog has to offer a module container creation functionality. In contrast to the other parts of the wizard, the creation of module containers in this dialog should be immediate and on file system level. This is important to comply with the conceptual model of eclipse and the operating system.</p>
@@ -693,7 +693,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier initial selection inference</a> (ver. 1)</p>
+<p><a id="Req-GH-1413m"></a><strong>Req. GH-1413m:</strong> <a href="#Req-GH-1413m">Module specifier initial selection inference</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>The module specifier should be derived from the initial selection by using the container of the selection as initial module container</p>
@@ -703,7 +703,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Module specifier content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413n"></a><strong>Req. GH-1413n:</strong> <a href="#Req-GH-1413n">Module specifier content assist</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Modules in the selected source folder</p>
@@ -724,7 +724,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Class name basic constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413o"></a><strong>Req. GH-1413o:</strong> <a href="#Req-GH-1413o">Class name basic constraints</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -752,7 +752,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Class name conflict validation</a> (ver. 1)</p>
+<p><a id="Req-GH-1413p"></a><strong>Req. GH-1413p:</strong> <a href="#Req-GH-1413p">Class name conflict validation</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>If the target module already exists no other type with the same identifier may exist in this module</p>
@@ -762,7 +762,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">File type options</a> (ver. 1)</p>
+<p><a id="Req-GH-1413q"></a><strong>Req. GH-1413q:</strong> <a href="#Req-GH-1413q">File type options</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -777,7 +777,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Access modifier constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413r"></a><strong>Req. GH-1413r:</strong> <a href="#Req-GH-1413r">Access modifier constraints</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Specifies the access modifiers of the class. One of <code>public</code>, <code>project</code>, <strong>private</strong>. <code>@Internal</code> is an additionally selectable option.</p>
@@ -816,7 +816,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Other modifiers constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413s"></a><strong>Req. GH-1413s:</strong> <a href="#Req-GH-1413s">Other modifiers constraints</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -845,7 +845,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Super class constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413t"></a><strong>Req. GH-1413t:</strong> <a href="#Req-GH-1413t">Super class constraints</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -870,7 +870,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Super class browse button</a> (ver. 1)</p>
+<p><a id="Req-GH-1413u"></a><strong>Req. GH-1413u:</strong> <a href="#Req-GH-1413u">Super class browse button</a> (ver. 1)</p>
</div>
<div class="hdlist">
<table>
@@ -889,7 +889,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Super class content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413v"></a><strong>Req. GH-1413v:</strong> <a href="#Req-GH-1413v">Super class content assist</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -912,7 +912,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Interfaces constraints</a> (ver. 1)</p>
+<p><a id="Req-GH-1413w"></a><strong>Req. GH-1413w:</strong> <a href="#Req-GH-1413w">Interfaces constraints</a> (ver. 1)</p>
</div>
<div class="olist arabic">
<ol class="arabic">
@@ -926,7 +926,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Interfaces browsing</a> (ver. 1)</p>
+<p><a id="Req-GH-1413x"></a><strong>Req. GH-1413x:</strong> <a href="#Req-GH-1413x">Interfaces browsing</a> (ver. 1)</p>
</div>
<div class="dlist">
<dl>
@@ -945,7 +945,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Interfaces content assist</a> (ver. 1)</p>
+<p><a id="Req-GH-1413y"></a><strong>Req. GH-1413y:</strong> <a href="#Req-GH-1413y">Interfaces content assist</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Text input is available by clicking in empty space at the end of the list. Content Assist provides all interfaces matching mentioned criteria.</p>
@@ -955,7 +955,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Create method stubs</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z1"></a><strong>Req. GH-1413z1:</strong> <a href="#Req-GH-1413z1">Create method stubs</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>Specifies if the wizard should generate method stubs for all abstract methods of the newly generated class. That are abstract super class methods or methods that need to be implemented by the class to conform to the selected interfaces.</p>
@@ -965,7 +965,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Create method stub conflict detection</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z2"></a><strong>Req. GH-1413z2:</strong> <a href="#Req-GH-1413z2">Create method stub conflict detection</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>If the selected interfaces are impossible to implement (e.g. method name overlap with unrelated parameter types) this option needs to be disabled and a warning needs to be shown.</p>
@@ -981,13 +981,13 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Visibility issue conflict solving</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z3"></a><strong>Req. GH-1413z3:</strong> <a href="#Req-GH-1413z3">Visibility issue conflict solving</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>By allowing the user to select invisible interfaces and super classes or unextendable <code>@Final</code>-annotated super classes, accessability issues may come up. The goal is to never generate a file containing invalid code. To accomplish this, conflicts must get solved before the file is generated.</p>
</div>
<div class="paragraph">
-<p>The slight limitation of the selection of interfaces and classes to elements from modifiable sources (cf. <a href="#Req-GH-1413">super class browse button</a>) allows to solve all possibly occurring visibility issues.</p>
+<p>The slight limitation of the selection of interfaces and classes to elements from modifiable sources (cf. <a href="#Req-GH-1413u">super class browse button</a>) allows to solve all possibly occurring visibility issues.</p>
</div>
<div class="paragraph">
<p>If the modifications by finishing the wizard do imply changes different from insertions and creations, a compare view is to be shown, giving the user an overview of the needed changes before they’re applied.</p>
@@ -1000,7 +1000,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Wizard generation</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z4"></a><strong>Req. GH-1413z4:</strong> <a href="#Req-GH-1413z4">Wizard generation</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>The following changes are to be made by the wizard:</p>
@@ -1032,7 +1032,7 @@
<div class="openblock requirement">
<div class="content">
<div class="paragraph">
-<p><a id="Req-GH-1413"></a><strong>Req. GH-1413:</strong> <a href="#Req-GH-1413">Generation preview</a> (ver. 1)</p>
+<p><a id="Req-GH-1413z5"></a><strong>Req. GH-1413z5:</strong> <a href="#Req-GH-1413z5">Generation preview</a> (ver. 1)</p>
</div>
<div class="paragraph">
<p>On the right of the wizard form a preview window should be provided. It should preview the full path of the generated file and all code that is generated with the options of the wizard. Changes should be updated in realtime as the user is choosing different options.</p>
@@ -1129,7 +1129,7 @@
</table>
</div>
<div class="paragraph">
-<p>See <a href="#Req-GH-1413">N4JS Class Wizard Modifier Field</a> except for the following point:</p>
+<p>See <a href="#Req-GH-1413r">N4JS Class Wizard Modifier Field</a> except for the following point:</p>
</div>
<div class="paragraph">
<p><em>Other than classes, interfaces must not be declared as <code>@Final</code>, therefore this option is removed.</em></p>
@@ -1173,7 +1173,7 @@
<h4 id="import-naming-conflicts"><a class="anchor" href="#import-naming-conflicts"></a><a class="link" href="#import-naming-conflicts">4.4.3. Import naming conflicts</a></h4>
<div class="paragraph">
<p>As the user may select identically named interfaces, the wizard has to solve these naming conflicts. See
-<strong><a href="#Req-GH-1413">Class Wizard Visibility Issues</a></strong> for details.</p>
+<strong><a href="#Req-GH-1413z3">Class Wizard Visibility Issues</a></strong> for details.</p>
</div>
</div>
<div class="sect3">
@@ -1315,7 +1315,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/N4JSSpec.html b/spec/N4JSSpec.html
index 747572d..e4454af 100644
--- a/spec/N4JSSpec.html
+++ b/spec/N4JSSpec.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -841,7 +841,7 @@
<div id="preamble">
<div class="sectionbody">
<div class="paragraph center">
-<p><strong>Last Updated: 2019-08-07</strong></p>
+<p><strong>Last Updated: 2019-08-08</strong></p>
</div>
<div class="paragraph center">
<p><strong>Authors:</strong><br>
@@ -4902,27 +4902,129 @@
</div>
</li>
<li>
-<p>Only one class must be contained in the intersection type:</p>
+<p>Only one nominally typed class must be contained in the intersection type:</p>
<div class="openblock">
<div class="content">
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close=")" open="("><mrow><mo>∃</mo><mi>C</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>C</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle></mrow></mfenced><mo>→</mo><mo>∄</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>∖</mo><mfenced close="}" open="{"><mi>C</mi></mfenced><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle></math>
+<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close=")" open="("><mrow><mo>∃</mo><mi>C</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>C</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle><mo>∧</mo><mi>C</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></mrow></mfenced><mo>→</mo><mo>∄</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>∖</mo><mfenced close="}" open="{"><mi>C</mi></mfenced><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle><mo>∧</mo><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math>
</div>
</div>
<div class="paragraph">
-<p>For the time being, only a warning is produced when more than one class is contained in the intersection type .</p>
+<p>A warning is produced when more than one nominal class is contained in the intersection type, since
+only undefined (or null) can be assigned to a type reference of this type.</p>
</div>
</li>
<li>
<p>Non-optional elements:</p>
-</li>
-</ol>
-</div>
<div class="openblock">
<div class="content">
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>→</mo><mo>¬</mo><mi>T</mi><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></math>
</div>
</div>
+</li>
+<li>
+<p>If the intersection contains multiple references to the same generic type, a warning is produced if only undefined (or null) can be assigned to a type reference of this type. There are some rare cases in which this does not happen. This is true if for all type arguments one of the following conditions hold:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>a type argument corresponding to a type parameter without def-site variance is a wildcard with an upper bound (use "extends" or no bound) or a type argument not defining an upper bound corresponds to a covariant (out) type parameter, and this constraint (IDE-27) holds for an intersection created from the upper bounds of the type argument (or the lower bound of the type parameter).</p>
+</li>
+<li>
+<p>a type argument is a wildcard with lower bounds (since Object would be a solution)</p>
+</li>
+</ul>
</div>
+</li>
+</ol>
+</div>
+</div>
+</div>
+<div class="paragraph">
+<p>Definition of structural typing attributes see <a href="#Req-ID-78701">[Req-ID-78701]</a>.</p>
+</div>
+<div class="paragraph">
+<p>The combination of intersection types and generics is a bit tricky. The following example demonstrates that:</p>
+</div>
+<div class="exampleblock">
+<div class="title">Example 20. Intersection and generics</div>
+<div class="content">
+<div class="paragraph">
+<p>Given the following types:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>class G<T> {
+ private T: t
+ set(t: T) { this.t = t;}
+ get(): T { return this.t; }
+}
+class C { public y; }
+class D { public x; }
+interface I {}</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>We use the generic with the getter and setter here only to demonstrate co- and contra variance effects.</p>
+</div>
+<div class="paragraph">
+<p>Let</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>let g1: G<C> & G<D>;</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>be a variable. We can only assign undefined to g1, since any other value would not be confirm to the intersection.
+If we for example would assign</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>let gc = new G<C>()
+g1 = gc;</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>we would run into contra-variance problems:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>gc.set(new C());</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This would implicitly also set a <code>C</code> in <code>g1</code>, which would not be compatible with <code>D</code>. This would lead to a problem in the following lines:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>let gd: G<D> = g1;
+let d: D = gd.get();</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This is the typical contra variance problem.</p>
+</div>
+</div>
+</div>
+<div class="paragraph">
+<p>Similar problems arise even with structural types.</p>
+</div>
+<div class="paragraph">
+<p>Note that in theory more warnings could be produced, in particular in combination with
+structural types (and the fact that N4JS classes must explicitly implement even
+structural interfaces). We omit these kind of warnings for two reasons:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>performance</p>
+</li>
+<li>
+<p>anticipated slight changes in semantics (e.g. we may remove the requirement of explicitly implementing structural interfaces)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Since problems caused by not instanceable type references will be detected by programmers before runtime anyway, we do not need to be strict here. They are merely convenience features and they do not affect the correctness of the type system.</p>
</div>
<div class="openblock requirement">
<div class="content">
@@ -4999,7 +5101,7 @@
We also implicitly use this representation in this specification.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 20. Subtyping with intersection type</div>
+<div class="title">Example 21. Subtyping with intersection type</div>
<div class="content">
<div class="paragraph">
<p>Let A, B, and C be defined as in the chapter beginning (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo><</mo><mi>:</mi><mi>B</mi><mo><</mo><mi>:</mi><mi>A</mi></math>)</p>
@@ -5558,7 +5660,7 @@
<li>
<p>Overriding of static methods is possible and by using the constructor or classifier type, polymorphism for static methods is possible as well.</p>
<div id="_polymorphism-and-static-methods" class="exampleblock">
-<div class="title">Example 21. Static Polymorphism</div>
+<div class="title">Example 22. Static Polymorphism</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -5582,7 +5684,7 @@
<p>It is even possible to refer to the constructor of an abstract class.
The abstract class itself cannot provide this constructor (it only provides a type..), that is to say only concrete subclasses can provide constructors compatible to the constructor.</p>
<div class="exampleblock">
-<div class="title">Example 22. Constructor of Abstract Class</div>
+<div class="title">Example 23. Constructor of Abstract Class</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -5685,7 +5787,7 @@
code shown in <a href="#ex-constructors-and-prototypes">Constructors and Prototypes</a>.</p>
</div>
<div id="ex-constructors-and-prototypes" class="exampleblock">
-<div class="title">Example 23. Constructors and Prototypes</div>
+<div class="title">Example 24. Constructors and Prototypes</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -5807,7 +5909,7 @@
See <a href="#_this-keyword">This Keyword</a> for details.</p>
</div>
<div id="ex:this-keyword-and-type-in-instance-and-static-context" class="exampleblock">
-<div class="title">Example 24. This keyword and type in instance and static context</div>
+<div class="title">Example 25. This keyword and type in instance and static context</div>
<div class="content">
<div class="paragraph">
<p>Note that the following code is not working, because some usages below are
@@ -5907,7 +6009,7 @@
</div>
<div style="page-break-after: always;"></div>
<div class="exampleblock">
-<div class="title">Example 25. This type in function-type-expression</div>
+<div class="title">Example 26. This type in function-type-expression</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -5927,7 +6029,7 @@
In the following example the problem is sketched up. <sup class="footnote">[<a id="_footnoteref_26" class="footnote" href="#_footnote_26" title="View footnote.">26</a>]</sup></p>
</div>
<div class="exampleblock">
-<div class="title">Example 26. Problems with this type and type arguments</div>
+<div class="title">Example 27. Problems with this type and type arguments</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -6153,7 +6255,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 27. Enumeration List</div>
+<div class="title">Example 28. Enumeration List</div>
<div class="content">
<div class="paragraph">
<p>Due to the common base type <code>N4Enum</code> it is possible to define generics accepting only enumeration, as shown in this example:</p>
@@ -6269,7 +6371,7 @@
</ol>
</div>
<div class="exampleblock">
-<div class="title">Example 28. WebIDL example</div>
+<div class="title">Example 29. WebIDL example</div>
<div class="content">
<div class="listingblock">
<div class="title">Gecko-Engine webIDL XMLHttpRequestResponseType as taken from [<a href="#W3C:Steen:14:XL">W3C:Steen:14:XL</a>]</div>
@@ -6795,7 +6897,7 @@
In Java, however, more constraints exist, (for example, methods of interfaces must be public).</p>
</div>
<div class="exampleblock">
-<div class="title">Example 29. Simple Class</div>
+<div class="title">Example 30. Simple Class</div>
<div class="content">
<div class="paragraph">
<p>This first example shows a very simple class with a field, a constructor and a method.</p>
@@ -6816,7 +6918,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 30. Extend and implement</div>
+<div class="title">Example 31. Extend and implement</div>
<div class="content">
<div class="paragraph">
<p>The following example demonstrate how a class can extend a superclass and implement an interface.</p>
@@ -7201,7 +7303,7 @@
<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mi>:</mi><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><msup><mo>≠</mo><mi>'</mi></msup><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><msup><mi>r</mi><mi>'</mi></msup></math>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 31. Simple Interfaces</div>
+<div class="title">Example 32. Simple Interfaces</div>
<div class="content">
<div class="paragraph">
<p>The following example shows the syntax for defining interfaces.
@@ -7359,7 +7461,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 32. Generic Type Definition and Usage as Type of Variable</div>
+<div class="title">Example 33. Generic Type Definition and Usage as Type of Variable</div>
<div class="content">
<div class="paragraph">
<p>This example demonstrates how to define a generic type and how to refer to it in a variable definition.</p>
@@ -7397,7 +7499,7 @@
<p>In line 3, the type variable <code>T</code> of the generic class <code>Container</code> is bound to <code>string</code>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 33. Binding of type variables with multiple types</div>
+<div class="title">Example 34. Binding of type variables with multiple types</div>
<div class="content">
<div class="paragraph">
<p>For a given generic class <code>G</code></p>
@@ -7632,7 +7734,7 @@
</div>
</div>
<div id="ex:use-site-declaration-variance" class="exampleblock">
-<div class="title">Example 34. Use-site declaration of variance</div>
+<div class="title">Example 35. Use-site declaration of variance</div>
<div class="content">
<div class="paragraph">
<p>For illustration purposes, let’s compare use-site and definition-site declaration of variance.
@@ -8212,7 +8314,7 @@
<p>Default methods in interfaces, cf. <a href="#_default-methods-in-interfaces">Default Methods in Interfaces</a>, may also be declared <code>@Final</code>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 35. Final Methods in Interfaces</div>
+<div class="title">Example 36. Final Methods in Interfaces</div>
<div class="content">
<div class="paragraph">
<p>If a method in an interface is provided with a body, it may be declared final.
@@ -8529,7 +8631,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 36. Field name conflicts with structural member name</div>
+<div class="title">Example 37. Field name conflicts with structural member name</div>
<div class="content">
<div class="paragraph">
<p>The situation described in <a href="#Req-IDE-58">[Req-IDE-58]</a> is demonstrated in the following code fragment:</p>
@@ -8739,7 +8841,7 @@
<p>The following examples illustrate further details of other use cases of spec constructors.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 37. Anonymous Interface in Constructor</div>
+<div class="title">Example 38. Anonymous Interface in Constructor</div>
<div class="content">
<div class="paragraph">
<p>The base class <code>A</code> in the examples redefines the constructor already defined in <code>N4Object</code>. This is not
@@ -8765,7 +8867,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 38. Spec Object and Subclasses</div>
+<div class="title">Example 39. Spec Object and Subclasses</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -8824,7 +8926,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 39. Superfluous Properties in @Spec Constructors</div>
+<div class="title">Example 40. Superfluous Properties in @Spec Constructors</div>
<div class="content">
<div class="paragraph">
<p>Each non-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></math> field has to be set in the constructor via the <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>with</mtext></mstyle></math> to the parameter otherwise properties are <em>not</em> used to set non-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></math> fields.</p>
@@ -8876,7 +8978,7 @@
<p>The following example illustrates this restriction.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 40. Interface fields that cannot be initialized via @Spec constructors</div>
+<div class="title">Example 41. Interface fields that cannot be initialized via @Spec constructors</div>
<div class="content">
<div class="listingblock">
<div class="title">Inf.n4jsd</div>
@@ -9044,7 +9146,7 @@
It shows a small class hierarchy using covariant constructors, <code>Cls</code> and <code>Cls2</code>, together with a helper function <code>createAnother</code> that creates and returns a new instance of the same type as its argument <code>value</code>.</p>
</div>
<div id="ex:covariant_constructors" class="exampleblock">
-<div class="title">Example 41. Covariant Constructors</div>
+<div class="title">Example 42. Covariant Constructors</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -9083,7 +9185,7 @@
<p>The next example illustrates how to use <code>@CovariantConstructor</code> with interfaces and shows a behavior that might be surprising at first sight.</p>
</div>
<div id="ex:covariant-constructors-in-interfaces" class="exampleblock">
-<div class="title">Example 42. Covariant Constructors in Interfaces</div>
+<div class="title">Example 43. Covariant Constructors in Interfaces</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -9398,7 +9500,7 @@
<p>Notes with regard to syntax: Although ECMAScript 6 does not define fields in classes, it defines getter and setter methods similarly (cf. [<a href="#ECMA15a">ECMA15a(p.S13.3, p.p.209)</a>]).</p>
</div>
<div class="exampleblock">
-<div class="title">Example 43. Getter and Setter</div>
+<div class="title">Example 44. Getter and Setter</div>
<div class="content">
<div class="paragraph">
<p>The getter and setter implementations usually reference data fields internally.
@@ -10021,7 +10123,7 @@
<p>It is even possible to call a static field accessor or method of a class using dynamic polymorphism, as demonstrated in the following example:</p>
</div>
<div id="ex:Polymorphism_and_static_methods" class="exampleblock">
-<div class="title">Example 44. Static members of classes, inheritance and polymorphism</div>
+<div class="title">Example 45. Static members of classes, inheritance and polymorphism</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -10061,7 +10163,7 @@
depending on the declared type of the receiver (and not its value):</p>
</div>
<div class="exampleblock">
-<div class="title">Example 45. Static members in Java</div>
+<div class="title">Example 46. Static members in Java</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -10129,7 +10231,7 @@
Compare the following example to <a href="#_polymorphism-and-static-methods">Static Polymorphism</a> for classes above:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 46. Static members of interfaces</div>
+<div class="title">Example 47. Static members of interfaces</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -10507,7 +10609,7 @@
We always use the <code>@Override</code> annotation.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 47. Method Consumption</div>
+<div class="title">Example 48. Method Consumption</div>
<div class="content">
<div class="paragraph">
<p><a href="#tab:methodConsumption">Consumption of methods</a> shows simple examples of above rules.
@@ -10594,7 +10696,7 @@
</dl>
</div>
<div class="exampleblock">
-<div class="title">Example 48. Field and Field Initializer Consumption</div>
+<div class="title">Example 49. Field and Field Initializer Consumption</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -10789,7 +10891,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 49. Declaration Site Structural Typing</div>
+<div class="title">Example 50. Declaration Site Structural Typing</div>
<div class="content">
<div class="paragraph">
<p>The following snippet demonstrates the effect of definition-site structural types by comparing them to
@@ -10894,7 +10996,7 @@
Nested structural types are evaluated on the fly when doing subtype checks.</p>
</div>
<div id="ex:nested-structural-typing-strategies" class="exampleblock">
-<div class="title">Example 50. Nested Structural Typing Strategies</div>
+<div class="title">Example 51. Nested Structural Typing Strategies</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -10913,7 +11015,7 @@
<p>The following example demonstrates the effect of the structural type modifiers:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 51. Effect of structural type modifiers on use-site</div>
+<div class="title">Example 52. Effect of structural type modifiers on use-site</div>
<div class="content">
<div class="paragraph">
<p>Let’s assume the type defined on the left.
@@ -11067,7 +11169,6 @@
</tr>
</tbody>
</table>
-<div style="page-break-after: always;"></div>
<div class="paragraph">
<p>Note that even if a type is defined without the structural modifier, it is not possible to use <code>instanceof</code> for variables declared as structural, as shown in the next example:</p>
</div>
@@ -11120,6 +11221,16 @@
</tr>
</tbody>
</table>
+</div>
+</div>
+<div class="openblock requirement">
+<div class="content">
+<div class="paragraph">
+<p><a id="Req-IDE-78701"></a><strong>Req. IDE-78701:</strong> <a href="#Req-IDE-78701">Nominal and structural typing spec attributes</a> (ver. 1)</p>
+</div>
+<div class="paragraph">
+<p>Within this spec, we define the following attributes of a type reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>:</p>
+</div>
<div class="ulist">
<ul>
<li>
@@ -11137,6 +11248,14 @@
<li>
<p>If a type is referenced with the structural initializer field type modifier <code>~i~</code>, then the property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>I</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math> is true.</p>
</li>
+<li>
+<p>We use <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math> to simply refer any structural typing, i.e.+
+<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mo>=</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mo>∨</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mo>∨</mo></math>T.refStructuralReadOnlyField \lor T.refStructuralWriteOnlyField || T.refStructuralInitField || T.defStructural$</p>
+</li>
+<li>
+<p>We use <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>N</mi><mi>o</mi><mi>m</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></math> as the opposite of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math>, i.e.<br>
+<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>N</mi><mi>o</mi><mi>m</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>=</mo><mo>¬</mo><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math></p>
+</li>
</ul>
</div>
<div class="paragraph">
@@ -11300,7 +11419,7 @@
applied.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 52. Use-Site Structural Typing</div>
+<div class="title">Example 53. Use-Site Structural Typing</div>
<div class="content">
<div class="paragraph">
<p>The following example demonstrates the effect of the structural (field) modifier, used in this case for function parameters.</p>
@@ -11323,7 +11442,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 53. Structural types variable and instanceof operator</div>
+<div class="title">Example 54. Structural types variable and instanceof operator</div>
<div class="content">
<div class="paragraph">
<p>It is possible to use a variable typed with a structural version of a type on the left hand side of the <code>instanceof</code> operator, as demonstrated in this example:</p>
@@ -11452,7 +11571,7 @@
The already-initialized <code>@Final</code> fields can be either omitted from, or can be re-initialized via, an initializer field typing <code>@Spec</code> style constructor.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 54. Subtype relationship between structural field typing</div>
+<div class="title">Example 55. Subtype relationship between structural field typing</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -11916,7 +12035,7 @@
<p>It is important to note that it is valid to use the <code>ProvidesInitializer</code> annotation for setters in <code>n4js</code> files and not only definition files.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 55. Setters with <code>@ProvidesInitializer</code> treated as optional</div>
+<div class="title">Example 56. Setters with <code>@ProvidesInitializer</code> treated as optional</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -11951,7 +12070,7 @@
visibility.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 56. Access modifier in structural typing</div>
+<div class="title">Example 57. Access modifier in structural typing</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -12063,7 +12182,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 57. Additional optional members in structural typing</div>
+<div class="title">Example 58. Additional optional members in structural typing</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -12085,7 +12204,7 @@
Hence, type variables must not be augmented with additional structural members like in the following example.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 58. Forbidden additional structural members on type variables</div>
+<div class="title">Example 59. Forbidden additional structural members on type variables</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -12101,7 +12220,7 @@
However, constraints like this should be rather stated using an explicit interface like in the example below.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 59. Use explicitly defined Interfaces</div>
+<div class="title">Example 60. Use explicitly defined Interfaces</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -12375,7 +12494,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 60. Function type conformance</div>
+<div class="title">Example 61. Function type conformance</div>
<div class="content">
<div class="paragraph">
<p>The following incomplete snippet demonstrates the usage of two function variables <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>1</mn></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>2</mn></math>, in which <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>f</mi><mn>2</mn></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mo><</mo><mi>:</mi><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>f</mi><mn>1</mn></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math> must hold true according to the aforementioned constraints.
@@ -12398,7 +12517,7 @@
<p>The type of <code>this</code> can be explicitly set via the <code>@This</code> annotation.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 61. Function Subtyping</div>
+<div class="title">Example 62. Function Subtyping</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -12421,7 +12540,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 62. Subtyping with function types</div>
+<div class="title">Example 63. Subtyping with function types</div>
<div class="content">
<div class="paragraph">
<p>If classes A, B, and C are defined as previously mentioned, i.e. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo><</mo><mi>:</mi><mi>B</mi><mo><</mo><mi>:</mi><mi>A</mi></math>, then
@@ -12583,7 +12702,7 @@
Where a particular type variable is used, on co- or contra-variant position, is not relevant:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 63. Bounded type variable at co-variant position in function type</div>
+<div class="title">Example 64. Bounded type variable at co-variant position in function type</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -12829,7 +12948,7 @@
This supertype contains all common properties of these two subtypes, that is, all properties of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></math>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 64. Function Declaration with Type Annotation</div>
+<div class="title">Example 65. Function Declaration with Type Annotation</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -12915,7 +13034,7 @@
This is demonstrated in the next example.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 65. Inference Of Function Expression’s Signature</div>
+<div class="title">Example 66. Inference Of Function Expression’s Signature</div>
<div class="content">
<div class="paragraph">
<p>In general, <code>{function():any}</code> is a subtype of <code>{function():void}</code> (cf. <a href="#_function-type">Function Type</a>).
@@ -13092,7 +13211,7 @@
Take this example:</p>
</div>
<div id="ex:two-simple-generator-functions" class="exampleblock">
-<div class="title">Example 66. Two simple generator functions</div>
+<div class="title">Example 67. Two simple generator functions</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -13422,7 +13541,7 @@
keyword, as shown in the next example.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 67. Async as keyword and identifier</div>
+<div class="title">Example 68. Async as keyword and identifier</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -13610,7 +13729,7 @@
Consider the example below.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 68. Type variables with async methods.</div>
+<div class="title">Example 69. Type variables with async methods.</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -13684,7 +13803,7 @@
This is particularly useful in N4JS definition files (.n4jsd) to allow using an existing callback-based API from N4JS code with the more convenient <code>await</code>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 69. Promisifiable</div>
+<div class="title">Example 70. Promisifiable</div>
<div class="content">
<div class="paragraph">
<p>Given a function with an N4JS signature</p>
@@ -13962,7 +14081,7 @@
That is, in most cases, no extra hint is passed to <code>DefaultValue</code>. Thus <code>valueOf</code> usually takes precedence over toString as demonstrated in the following example:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 70. Auto-Conversion</div>
+<div class="title">Example 71. Auto-Conversion</div>
<div class="content">
<div class="paragraph">
<p>Assume some classes and corresponding instances defined as follows:</p>
@@ -14138,7 +14257,7 @@
<p>In order to avoid errors at runtime, the <code>instanceof</code> operator defines appropriate constraints, see <a href="#_relational-expression">Relational Expression</a> for details.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 71. Type Check Example</div>
+<div class="title">Example 72. Type Check Example</div>
<div class="content">
<div class="paragraph">
<p>Given the following classes and variable:</p>
@@ -14241,7 +14360,7 @@
the constructor of <code>C</code> available, for example because the constructor is not accessible.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 72. Reflection with <code>N4class</code></div>
+<div class="title">Example 73. Reflection with <code>N4class</code></div>
<div class="content">
<div class="paragraph">
<p>This example demonstrates how these reflective features are accessed:</p>
@@ -14277,7 +14396,7 @@
They are not defined in a module, thus their <a href="#_acronyms">FQN</a> returns only their simple name.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 73. Reflection with Built-In Types</div>
+<div class="title">Example 74. Reflection with Built-In Types</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -14315,7 +14434,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 74. N4Class.of</div>
+<div class="title">Example 75. N4Class.of</div>
<div class="content">
<div class="paragraph">
<p>The type has a method to retrieve the meta-information from instances (i.e. or enumeration literals using )
@@ -14579,7 +14698,7 @@
Type inference heuristics and explanations are provided in the next section.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 75. This in Unrestricted Mode</div>
+<div class="title">Example 76. This in Unrestricted Mode</div>
<div class="content">
<div class="paragraph">
<p>In unrestricted mode, <code>this</code> is bound to the receiver.
@@ -14611,7 +14730,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 76. This in strict mode</div>
+<div class="title">Example 77. This in strict mode</div>
<div class="content">
<div class="paragraph">
<p>In strict mode, <code>this</code> is bound to the receiver.
@@ -14645,7 +14764,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 77. This in N4JS mode</div>
+<div class="title">Example 78. This in N4JS mode</div>
<div class="content">
<div class="paragraph">
<p>As in strict mode, <code>this</code> is bound to the receiver and if there is no receiver, it is bound to <code>undefined</code>. So the example above is also true for N4JS mode.
@@ -14811,7 +14930,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 78. Effect of Nominal This Type</div>
+<div class="title">Example 79. Effect of Nominal This Type</div>
<div class="content">
<div class="paragraph">
<p>Given the following declaration</p>
@@ -14851,7 +14970,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 79. This and Function Declaration</div>
+<div class="title">Example 80. This and Function Declaration</div>
<div class="content">
<div class="paragraph">
<p>This example demonstrates the usage of functions annotated with <code>@This</code>.
@@ -14880,7 +14999,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 80. This and Function Expressions</div>
+<div class="title">Example 81. This and Function Expressions</div>
<div class="content">
<div class="paragraph">
<p>In this example a function is created via a function expression.
@@ -15265,7 +15384,7 @@
<p>Note that <code>typeof [1,2,3]</code> does not return <code>Array<number></code> (as ECMAScript is not aware of the generic array type), but <code>Object</code>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 81. Array Type Inference</div>
+<div class="title">Example 82. Array Type Inference</div>
<div class="content">
<div class="paragraph">
<p>The type for all variables declared in this example is inferred to <code>Array<string></code>:</p>
@@ -15547,7 +15666,7 @@
<div class="sect4">
<h5 id="_scoping-and-linking"><a class="anchor" href="#_scoping-and-linking"></a><a class="link" href="#_scoping-and-linking">8.1.5.2. Scoping and linking</a></h5>
<div class="exampleblock">
-<div class="title">Example 82. Scoping and linking</div>
+<div class="title">Example 83. Scoping and linking</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -15624,7 +15743,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 83. Parenthesized Expression Type Examples</div>
+<div class="title">Example 84. Parenthesized Expression Type Examples</div>
<div class="content">
<div class="paragraph">
<p>In the following listing, the type of the plain expressions is equivalent to the parenthesized versions:</p>
@@ -15840,7 +15959,7 @@
<p>Although index access is very limited, it is still possible to use immediate instances of <code>Object</code> in terms of a map (but this applies only to index access, not the dot notation):</p>
</div>
<div class="exampleblock">
-<div class="title">Example 84. Object as Map</div>
+<div class="title">Example 85. Object as Map</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -16004,7 +16123,7 @@
<p>to <a href="#new-expression-3">3</a> It is not possible to refer to union or intersection at that location. So this is not explicitly denied here since it is not possible anyway.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 85. Abstract classes and construction</div>
+<div class="title">Example 86. Abstract classes and construction</div>
<div class="content">
<div class="paragraph">
<p>The following examples demonstrates the usage of abstract classes and constructor types, to make the first two constraints more clearer:</p>
@@ -16173,7 +16292,7 @@
See <a href="#_property-accessors">Property Accessors</a> for semantics and type inference.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 86. Generic Method Invocation</div>
+<div class="title">Example 87. Generic Method Invocation</div>
<div class="content">
<div class="paragraph">
<p>This examples demonstrate how to explicitly
@@ -16501,7 +16620,7 @@
<p>Adding two integers (int) leads to a number, since the result may not be represented as an (JavaScript) int anymore.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 87. Type of addition expression</div>
+<div class="title">Example 88. Type of addition expression</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -16698,7 +16817,7 @@
The compiler rewrites the code to make this work.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 88. <code>instanceof</code> with Interface</div>
+<div class="title">Example 89. <code>instanceof</code> with Interface</div>
<div class="content">
<div class="paragraph">
<p>The following example demonstrates the use of the operator with an interface.
@@ -16964,7 +17083,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 89. Type of Conditional Expressions</div>
+<div class="title">Example 90. Type of Conditional Expressions</div>
<div class="content">
<div class="paragraph">
<p>Given the following declarations:</p>
@@ -17144,7 +17263,7 @@
<p>All expressions will be evaluated even though only the value of the last expression will be the result.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 90. Comma Expression</div>
+<div class="title">Example 91. Comma Expression</div>
<div class="content">
<div class="paragraph">
<p>Assignment expressions preceed comma expressions:</p>
@@ -17186,7 +17305,7 @@
there are two use cases for keyword <code>super</code>: super member access and super constructor calls.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 91. Super Keyword</div>
+<div class="title">Example 92. Super Keyword</div>
<div class="content">
<div class="paragraph">
<p>Two use cases for keyword super:</p>
@@ -17372,7 +17491,7 @@
This is important in particular for static methods as demonstrated in the following example:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 92. Super Call in Static Methods</div>
+<div class="title">Example 93. Super Call in Static Methods</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -17763,7 +17882,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 93. Variable Statement</div>
+<div class="title">Example 94. Variable Statement</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -18373,7 +18492,7 @@
<p>Also see compilation as described in <a href="#_modules">Modules</a>, for semantics see <a href="#import-statement-semantics">Import Statement Semantics</a>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 94. Import</div>
+<div class="title">Example 95. Import</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -18566,7 +18685,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 95. Imports</div>
+<div class="title">Example 96. Imports</div>
<div class="content">
<div class="paragraph">
<p>Imports cannot be duplicated:</p>
@@ -18801,7 +18920,7 @@
</dl>
</div>
<div class="exampleblock">
-<div class="title">Example 96. Export</div>
+<div class="title">Example 97. Export</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -19082,7 +19201,7 @@
<p>If no matching error is found, the annotation itself will issue an error.</p>
</div>
<div id="ex:IDEBUG" class="exampleblock">
-<div class="title">Example 97. IDEBUG Example</div>
+<div class="title">Example 98. IDEBUG Example</div>
<div class="content">
<div class="paragraph">
<p>In the following code snippet, two errors are to be transformed to warnings.</p>
@@ -19484,7 +19603,7 @@
(injector of the DIComponent annotated with <code>@WithParentInjector</code>).</p>
</div>
<div class="exampleblock">
-<div class="title">Example 98. Simple DIComponents Relation</div>
+<div class="title">Example 99. Simple DIComponents Relation</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -19544,7 +19663,7 @@
</div>
</div>
<div id="ex:complex-dicomponents-relations" class="exampleblock">
-<div class="title">Example 99. Complex DIComponents Relations</div>
+<div class="title">Example 100. Complex DIComponents Relations</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -19768,7 +19887,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 100. Simple Field Injection</div>
+<div class="title">Example 101. Simple Field Injection</div>
<div class="content">
<div class="paragraph">
<p><a href="#ex:field-injection">Simple Field Injection</a> demonstrates simple field injection using default bindings.
@@ -21430,7 +21549,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 101. Static polyfill</div>
+<div class="title">Example 102. Static polyfill</div>
<div class="content">
<div class="paragraph">
<p><a href="#ex:staticpolyfill-genmod">Static Polyfill, Genmod</a> shows an example of generated code.
@@ -21947,7 +22066,7 @@
</dl>
</div>
<div class="exampleblock">
-<div class="title">Example 102. Module Filters</div>
+<div class="title">Example 103. Module Filters</div>
<div class="content">
<div class="paragraph">
<p>A simple and a source-container-specific module filter in the <code>n4js</code> section of a package.json file.</p>
@@ -22087,14 +22206,14 @@
by default.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 103. A package.json file with N4JS-specific properties.</div>
+<div class="title">Example 104. A package.json file with N4JS-specific properties.</div>
<div class="content">
<div class="paragraph">
<p>The following example illustrates how to use the N4JS-related package.json properties.</p>
</div>
<div class="listingblock">
<div class="content">
-<pre class="highlight"><code>{
+<pre class="highlight"><code class="language-n4js" data-lang="n4js">{
"name": "SampleProject",
"version": "0.0.1",
"author": "Enfore AG",
@@ -22386,7 +22505,7 @@
<div class="listingblock">
<div class="title">Package.json: Important properties for type definition projects</div>
<div class="content">
-<pre class="highlight"><code>{
+<pre class="highlight"><code class="language-n4js" data-lang="n4js">{
"n4js": {
"projectType": "definition"
"definesPackage": "..."
@@ -23038,7 +23157,7 @@
</div>
</div>
<div id="external-definitions-and-implementations" class="exampleblock">
-<div class="title">Example 104. External Definitions and Their Implementations</div>
+<div class="title">Example 105. External Definitions and Their Implementations</div>
<div class="content">
<div class="paragraph">
<p>If, in addition to standard <code>source</code>, the <code>source-external</code> fragment is provided in <code>Sources</code>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mn>4</mn><mi>j</mi><mi>s</mi><mi>d</mi></math> files in the folder tree below source folders
@@ -23059,7 +23178,7 @@
<p>Assume the following non-N4JS module:</p>
</div>
<div id="ex:External_Classes_Example" class="exampleblock">
-<div class="title">Example 105. External Classes</div>
+<div class="title">Example 106. External Classes</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -23116,7 +23235,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 106. Structurally-typed external interfaces</div>
+<div class="title">Example 107. Structurally-typed external interfaces</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -23277,7 +23396,7 @@
Here, an example of applying a runtime polyfill is detailed.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 107. Object.observe with Polyfill</div>
+<div class="title">Example 108. Object.observe with Polyfill</div>
<div class="content">
<div class="paragraph">
<p>The following snippet demonstrates how to define a polyfill of the built-in class <code>Object</code> to add the new ECMAScript 7 observer functionality.
@@ -23404,7 +23523,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 108. @testee</div>
+<div class="title">Example 109. @testee</div>
<div class="content">
<div class="paragraph">
<p>The target element is to be fully qualified including the module specifier. The module specifier is simply
@@ -23433,7 +23552,7 @@
the interfaces tested in the base class.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 109. Usage of testeeFromType</div>
+<div class="title">Example 110. Usage of testeeFromType</div>
<div class="content">
<div class="paragraph">
<p>In the following example, the is used. This tag will lead to a test documentation for <code>B.foo</code> and <code>C.foo</code>.</p>
@@ -23503,7 +23622,7 @@
</table>
</div>
<div id="ex:testeetype-and-testeemethod" class="exampleblock">
-<div class="title">Example 110. testeeType and testeeMethod</div>
+<div class="title">Example 111. testeeType and testeeMethod</div>
<div class="content">
<div class="paragraph">
<p>Assume the following testees:</p>
@@ -23586,7 +23705,7 @@
</table>
</div>
<div class="exampleblock">
-<div class="title">Example 111. testeeType and testeeMethod with omitted constraints</div>
+<div class="title">Example 112. testeeType and testeeMethod with omitted constraints</div>
<div class="content">
<div class="paragraph">
<p>Assume testees similar as in <a href="#ex:testeetype-and-testeemethod">testeeType and testeeMethod</a>. Since the semantics of <code>bar</code> is not changed in <code>B</code>, it is probably not necessary to generate the same constraint in the documentation for <code>bar</code> twice (one in the section for class <code>A</code> and another one in the section of class <code>B</code>).
@@ -27585,7 +27704,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/N4JSSpec.xml b/spec/N4JSSpec.xml
deleted file mode 100644
index 67bab11..0000000
--- a/spec/N4JSSpec.xml
+++ /dev/null
@@ -1,21057 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<?asciidoc-toc maxdepth="5"?>
-<?asciidoc-numbered maxdepth="5"?>
-<book xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
-<info>
-<title>N4JS Language Specification</title>
-<date>2019-08-07</date>
-<author>
-<personname>
-<firstname>2019-08-07 15:02:40 CEST</firstname>
-</personname>
-</author>
-<authorinitials>{</authorinitials>
-<style>
- .admonitionblock td.icon .icon-todo:before{content:"\f249";color:#f4ee42}
- </style>
-</info>
-<preface>
-<title></title>
-<simpara role="center"><emphasis role="strong">Last Updated: 2019-08-07</emphasis></simpara>
-<simpara role="center"><emphasis role="strong">Authors:</emphasis><?asciidoc-br?>
-Jens von Pilgrim, Jakub Siberski, Mark-Oliver Reiser, Torsten Krämer, Ákos Kitta, Sebastian Zarnekow, Lorenzo Bettini, Jörg Reichert, Kristian Duske, Marcus Mews, Minh Quang Tran, Luca Beurer-Kellner</simpara>
-<simpara><?asciidoc-pagebreak?></simpara>
-<bridgehead xml:id="_abstract" renderas="sect1">Abstract</bridgehead>
-<simpara>This document contains the N4JS Specification.</simpara>
-<simpara><?asciidoc-pagebreak?></simpara>
-</preface>
-<chapter xml:id="_introduction">
-<title>Introduction</title>
-<simpara>This specification defines the N4JS language.</simpara>
-<simpara>In general, the N4JS JavaScript dialect used is identical to the standard ECMAScript as defined in the 6th edition of
-ECMA-262, also known as ECMAScript 2015, referred to as [<link linkend="ECMA15a">ECMA15a</link>].</simpara>
-<section xml:id="_notation" role="language-n4js">
-<title>Notation</title>
-<section xml:id="_grammar-notation">
-<title>Grammar Notation</title>
-<simpara>For the specification of the syntax and structure of elements, we use a
-slightly augmented similar to the grammar language of Xtext <link xl:href="http://www.eclipse.org/Xtext/documentation/301_grammarlanguage.html">Grammar Language</link>.</simpara>
-<simpara>Similar to [<link linkend="ECMA11a">ECMA11a</link>], we define types with properties only for the purpose of explanation and usage within this specification.
-We use the Xtext notation style to assign values to meta-properties.
-Particularly, we use the Xtext notation for collection (<literal>+=</literal>) and boolean (<literal>?=</literal>) values.
-These properties are written in italics. Enumerations are defined similar to Xtext.
-In order to allow the specification of default values, which are often defined by omitting the value, we always define the literal explicitly if it can be defined by the user.</simpara>
-<simpara>The following lists informally defines the grammar:</simpara>
-<variablelist>
-<varlistentry>
-<term>Terminal</term>
-<listitem>
-<simpara>Terminals (or terminal strings) are enclosed in single quotes, e.g., <literal>terminal</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Enumerations</term>
-<listitem>
-<simpara>Rules which contain only terminals used as values for properties are
-marked with <literal>enum</literal> for enumeration.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Properties</term>
-<listitem>
-<simpara>Values of non-terminals, e.g., other rules, can be assigned to
-properties. The property name and the assignment are not part of the
-original syntax and only used for the meta description. E.g., <literal><emphasis>name=</emphasis>Identifier</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Collection Properties</term>
-<listitem>
-<simpara>If a property is a collection, values are added to that list via <literal>+=</literal>.
-E.g.,<literal><emphasis>property+=</emphasis>Value</literal> .</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Boolean Properties</term>
-<listitem>
-<simpara>Boolean properties are set to false by default, if the value (usually
-a terminal) is found, the boolean value is set to true. Often, the
-name of the property is similar to the terminal. E.g., <literal><emphasis>final?</emphasis>='final'?</literal>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Properties of a non-terminal are sometimes listed again below the
-grammar. In that case, often pseudo properties are introduced which are
-derived from other properties and which are only used for
-simplification.</simpara>
-</section>
-<section xml:id="_type-judgments-and-rules-and-constraints-notation">
-<title>Type Judgments and Rules and Constraints Notation</title>
-<section xml:id="_typing-rules-and-judgments">
-<title>Typing Rules and Judgments</title>
-<definition>
-<title>Rule</title>
-<simpara>
-<anchor xml:id="rule" xreflabel="[rule]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="rule">Rule</link></simpara>
-<simpara>
-
-We use the common notation for rules such as type inference rules <footnote><simpara>A brief introduction can be found at <link xl:href="http://www.cs.cornell.edu/~ross/publications/mixedsite/tutorial.html">http://www.cs.cornell.edu/~ross/publications/mixedsite/tutorial.html</link>. In general, we refer the reader to [<link linkend="Pierce02a">Pierce02a</link>]</simpara></footnote>, that is</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>p</mi><mi>r</mi><mi>e</mi><mi>m</mi><mi>i</mi><mi>s</mi><mi>e</mi><mi>s</mi></mrow><mrow><mi>c</mi><mi>o</mi><mi>n</mi><mi>c</mi><mi>l</mi><mi>u</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></mrow></mfrac><mspace width="5.0mm"/><mstyle mathvariant="normal"><mtext>rule name</mtext></mstyle></math>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mi>r</mi><mi>e</mi><mi>m</mi><mi>i</mi><mi>s</mi><mi>e</mi><mi>s</mi></math> is the rule’s premises (e.g., the expression to be inferred), <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>o</mi><mi>n</mi><mi>c</mi><mi>l</mi><mi>u</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></math> the result of the rule.
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>r</mi><mi>u</mi><mi>l</mi><mi>e</mi><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math> is an optional condition which may be omitted.</simpara>
-<simpara>Both parts of the rule may contain multiple expressions, which are concatenated via 'and'.</simpara>
-<simpara>For example, the following</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><msub><mi>P</mi><mn>1</mn></msub><mspace width="5.0mm"/><msub><mi>P</mi><mn>2</mn></msub><mspace width="5.0mm"/><msub><mi>P</mi><mn>3</mn></msub></mrow><mi>C</mi></mfrac></math>
-<simpara>can be read as</simpara>
-<blockquote>
-<simpara>if <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>P</mi><mn>1</mn></msub></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>P</mi><mn>2</mn></msub></math>, <emphasis>and</emphasis> <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>P</mi><mn>3</mn></msub></math> are all true, then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> is true as well.</simpara>
-</blockquote>
-</definition>
-<simpara>The following judgments (with relation symbols) are used:</simpara>
-<variablelist>
-<varlistentry>
-<term>subtype <math xmlns="http://www.w3.org/1998/Math/MathML"><mo><</mo></math> </term>
-<listitem>
-<simpara>-</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>type <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle></math> </term>
-<listitem>
-<simpara>in which the left hand side is a declaration or expression, and the right hand side a type.
-We also use <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math> as a function returning the (inferred) type of an expression.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>expectedTypeIn <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>⊲</mo><mi>:</mi></math> </term>
-<listitem>
-<simpara>a relation with three arguments:
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>⊲</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>:</mi><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> means, that
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></math> is expected to be a subtype of
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> inside <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The following statement, for example, defines transitivity of subtypes
-(in a simplified manner):</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi><mspace width="5.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>C</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>B</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>C</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></mrow></mfrac></math>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>⊢</mo></math> is the context containing (bound) type variables etc., <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>⊢</mo></math> can be read as <literal>entails</literal>.
-Thus, the rule can be read as follows:</simpara>
-<blockquote>
-<simpara>if the type B is a subtype of type A in context <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi></math> (i.e. with constraints on type variables specified in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi></math>), and if type C is a subtype of B, then C is also a subtype of A in context <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi></math>.</simpara>
-</blockquote>
-<simpara>In rules, we sometimes omit the environment if it is not needed.
-New information is sometimes added to the environment, in particular, substitutions (that is binding type variables to a type).
-The set of substitutions is written with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>θ</mi></math> (theta).
-If new substitutions are explicitly added to that set, we write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>θ</mi><mfenced close=")" open="("><mrow><mi>V</mi><mo>←</mo><mi>T</mi></mrow></mfenced></math> (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>V</mi></math> is substituted with type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>).
-Often, these bindings are computed from a parameterized type reference which declares type arguments which are bound to the type variables of the generic declaration.
-In this case we simply write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>θ</mi><mfenced close=")" open="("><mi>p</mi></mfenced></math>, in which <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi></math> is the parameterized type declaration.
-As these new substitutions must become part of a (newly) created environment, we then usually write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>←</mo><mi>θ</mi><mfenced close=")" open="("><mi>p</mi></mfenced></math>.
-These substitutions are usually omitted.</simpara>
-</section>
-<section xml:id="_types-of-an-element">
-<title>Types of an Element</title>
-<simpara>A variable or other typed element may be associated with three types:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Declared type: the type explicitly specified in the code, e.g., <literal>var s: string</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Inferred type: the type inferred by the type inferencer, e.g., <literal>var s = "Hello"</literal> infers the type of s to <literal>string</literal>. I.e.
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>⊢</mo><mi>s</mi><mi>:</mi><mrow><mi>s</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>n</mi><mi>g</mi></mrow></math> will be true, or <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mi>s</mi><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>s</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>n</mi><mi>g</mi></math>.
-If an element is annotated with a type ,i.e. it has a declared type, the inferred type will always be the declared type.</simpara>
-</listitem>
-<listitem>
-<simpara>Actual type: the actual type of a variable during runtime.
-This type information is not available at compile time and ignored in this specification.</simpara>
-</listitem>
-</orderedlist>
-<simpara>These types are not type declarations but type references, in fact, as they may be parameterized.
-For the sake of simplicity, we often omit the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi><mi>e</mi><mi>f</mi></math> suffix to shorten formulas.
-Consequently, we define the following properties and pseudo properties for typed elements such as variables:</simpara>
-<variablelist>
-<varlistentry>
-<term>declaredType<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi><mi>e</mi><mi>f</mi></math> </term>
-<listitem>
-<simpara>The explicitly declared type, this is usually a real property of the construct.
-Not all elements allow the specification of a declared type, such as expressions.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>inferredType<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi><mi>e</mi><mi>f</mi></math> or <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math></term>
-<listitem>
-<simpara>This pseudo property is the inferred type computed by the type inferencer.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>type<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi><mi>e</mi><mi>f</mi></math> </term>
-<listitem>
-<simpara>A pseudo property for elements with a <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> property.
-It is similar to the inferred type, i.e. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mi>e</mi><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-</section>
-</section>
-<section xml:id="_auxiliary-functions" role="language-n4js">
-<title>Auxiliary Functions</title>
-<simpara>This section describes some auxiliary functions required for definition of type inference rules later on.</simpara>
-<section xml:id="_binding">
-<title>Binding</title>
-<simpara>Binding an identifier (variable reference) to a variable declaration (or
-variable definition) is not part of this specification as this is
-standard ECMAScript functionality. However, some valid ECMAScript
-bindings are permitted due to visibility constraints.</simpara>
-<definition>
-<title>Binding Relation</title>
-<simpara>
-<anchor xml:id="binding_relation" xreflabel="[binding_relation]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="binding_relation">Binding Relation</link></simpara>
-<simpara>
-
-We define a pseudo relation</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mi>:</mi><mi>V</mi><mi>a</mi><mi>r</mi><mi>i</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>e</mi><mi>r</mi><mi>e</mi><mi>n</mi><mi>c</mi><mi>e</mi><mo>×</mo><mi>V</mi><mi>a</mi><mi>r</mi><mi>i</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi></math>
-<simpara>which binds a reference, i.e. an identifier, to a declaration (e.g.,variable declaration).</simpara>
-<simpara>Binding of variable references to declaration is defined by ECMAScript already.
-Type references only occur in type expressions, how these are handled is explained in <xref linkend="_type-expressions"/>.</simpara>
-<simpara>We usually omit this binding mechanism in most rules and use the reference similarly to the declaration or definition it is bound to.
-If a variable reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>r</mi></math>, for example, is bound to a variable declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math>, i.e. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></math>, we simply write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>r</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> instead of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced><mo>,</mo><mi>D</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> to refer to the type expression
-(of the variable).<footnote><simpara>One can interpret this similar to delegate methods, that is, instead of writing <literal role="language-n4js">r.binding().getType()</literal>, a method <literal role="language-n4js">r.getType()\{return binding().getType();</literal> is defined.</simpara></footnote></simpara>
-</definition>
-<simpara>A <literal>DeclaredType</literal> references the type declaration by its simple name that has been imported from a module specifier.
-We define the method <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi></math> for declared types as well:</simpara>
-<definition>
-<title>Binding Relation of Types</title>
-<simpara>
-<anchor xml:id="binding_relation_of_types" xreflabel="[binding_relation_of_types]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="binding_relation_of_types">Binding Relation of Types</link></simpara>
-<simpara>
-
-We define a pseudo relation</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mi>:</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>×</mo><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mo>|</mo><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mo>|</mo><mi>E</mi><mi>n</mi><mi>u</mi><mi>m</mi></math>
-<simpara>which binds a type reference, i.e. a simple name, to the type declaration.</simpara>
-</definition>
-</section>
-<section xml:id="_merging-types">
-<title>Merging Types</title>
-<simpara>In some cases we have to merge types, e.g., types of a union type or item types of an array.
-For that purpose, we define a method <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>r</mi><mi>g</mi><mi>e</mi></math> as follows.</simpara>
-<definition>
-<title>Merge Function</title>
-<simpara>
-<anchor xml:id="merge_function" xreflabel="[merge_function]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="merge_function">Merge Function</link></simpara>
-<simpara>
-
-We define a pseudo function</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>m</mi><mi>e</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>:</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>×</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>×</mo><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>⇒</mo><mi mathvariant="script">P</mi><mfenced close=")" open="("><mrow><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></mrow></mfenced></math>
-<simpara>The idea of this function is to remove duplicates.
-For example; if a union type contains two type expressions <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><msub><mi>e</mi><mn>1</mn></msub></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><msub><mi>e</mi><mi>k</mi></msub></math>, and if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>τ</mi><mfenced close=")" open="("><mrow><mi>t</mi><msub><mi>e</mi><mn>1</mn></msub></mrow></mfenced><mo>=</mo><mi>τ</mi><mfenced close=")" open="("><mrow><mi>t</mi><msub><mi>e</mi><mn>2</mn></msub></mrow></mfenced></math>, then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>r</mi><mi>g</mi><mi>e</mi><mfenced close=")" open="("><mrow><mi>τ</mi><mfenced close=")" open="("><mrow><mi>t</mi><msub><mi>e</mi><mn>1</mn></msub></mrow></mfenced></mrow><mrow><mi>τ</mi><mfenced close=")" open="("><mrow><mi>t</mi><msub><mi>e</mi><mn>2</mn></msub></mrow></mfenced></mrow></mfenced></math> contains only one element.
-The order of the elements is lost, however.</simpara>
-</definition>
-<section xml:id="_logic-formulas">
-<title>Logic Formulas</title>
-<simpara>In general, we use a pragmatic mixture of pseudo code, predicate logic, and OCL.
-Within constraints (also within the inference rules), the properties defined in the grammar are used.</simpara>
-<simpara>In some rules, it is necessary to type the rule variables.
-Instead of explicitly checking the metatype (via <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>X</mi></mfenced><mo>=</mo><mi>:</mi><mrow><mi>M</mi><mi>e</mi><mi>t</mi><mi>a</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></mrow></math>), we precede the variable with the type, that is: <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mi>M</mi><mi>e</mi><mi>t</mi><mi>a</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></mrow><mi>X</mi></math>.</simpara>
-<simpara>Instead of "type casting" elements, often properties are simply accessed.
-If an element does not define that element, it is either assumed to be false or null by default.</simpara>
-<simpara>If a property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi></math> is optional and not set, we write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mo>=</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></math> to test its absence.
-Note that <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mo>=</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></math> is different from <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mo>=</mo><mi>N</mi><mi>u</mi><mi>l</mi><mi>l</mi></math>, as the latter refers to the null type.
-Non-terminals may implicitly be subclasses.
-In that case, the concrete non-terminal, or type, of a property may be subject for a test in a constraint.</simpara>
-</section>
-</section>
-<section xml:id="_symbols-and-font-convention">
-<title>Symbols and Font Convention</title>
-<simpara>Variables and their properties are printed in italic when used in formulas (such as rules).
-A dot-notation is used for member access, e.g. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math>.
-Also defined functions are printed in italic, e.g., <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>c</mi><mi>c</mi><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></math>.
-Properties which define sets are usually ordered and we assume 0-indexed access to elements, the index subscripted, e.g., <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><msub><mi>s</mi><mi>i</mi></msub></math>.</simpara>
-<simpara>We use the following symbols and font conventions:</simpara>
-<variablelist>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∧</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∨</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>⊕</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo></math></term>
-<listitem>
-<simpara>Logical and, or, exclusive or (xor), and not.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>⇒</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>⇔</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="bold"><mtext>if</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="bold"><mtext>then</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="bold"><mtext>else</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></math> </term>
-<listitem>
-<simpara>Logical implication, if and only if, and if-then-else.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>false</mtext></mstyle></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>∅</mi></math></term>
-<listitem>
-<simpara>Boolean true, boolean false, null (i.e., not specified, e.g.,
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mo>=</mo></math> means that there are is no <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><mi>p</mi></math>
-(super class) specified), empty set.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∈</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∉</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∪</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∩</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>x</mi><mo>|</mo></math></term>
-<listitem>
-<simpara>Element of, not an element of, union set, intersection set,
-cardinality of set x.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi mathvariant="script">P</mi><mfenced close=")" open="("><mi>X</mi></mfenced></math></term>
-<listitem>
-<simpara>Power set of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math>, i.e.
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi mathvariant="script">P</mi><mfenced close=")" open="("><mi>X</mi></mfenced><mo>=</mo><mfenced close="}" open="{"><mrow><mi>U</mi><mi>:</mi><mi>U</mi><mo>⊆</mo><mi>X</mi></mrow></mfenced></math>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∃</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∄</mo></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo></math></term>
-<listitem>
-<simpara>Exists, not exists, for all; we write <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∃</mo><mi>x</mi><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><mi>z</mi><mi>:</mi><mi>P</mi><mfenced close=")" open="("><mi>x</mi><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mi>z</mi></mfenced></math> and say</simpara>
-<blockquote>
-<simpara>"there exists <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>x</mi><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><mi>z</mi></math> such that predicate <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> is true".</simpara>
-</blockquote>
-<simpara>Note that <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∄</mo><mi>x</mi><mi>:</mi><mi>P</mi><mfenced close=")" open="("><mi>x</mi></mfenced><mo>⇔</mo><mo>∀</mo><mi>x</mi><mi>:</mi><mo>¬</mo><mi>P</mi><mfenced close=")" open="("><mi>x</mi></mfenced></math>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow></mfenced></math></term>
-<listitem>
-<simpara>(mu) read "<emphasis role="strong">metatype of</emphasis>"; metatype of a variable or property, e.g.,</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mstyle mathvariant="bold"><mtext>if</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>x</mi></mfenced><mo>=</mo><mi>:</mi><mrow><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi></mrow><mstyle mathvariant="bold"><mtext>then</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mstyle mathvariant="bold"><mtext>else</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></math>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mover accent="true"><mi>x</mi><mo>¯</mo></mover></math></term>
-<listitem>
-<simpara>Sequence of elements <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>x</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>x</mi><mi>n</mi></msub></math>. E.g., if we want to
-define a constraint that the owner of a members of a class
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> is the class, we simply write</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>C</mi><mo>.</mo><mover accent="true"><mrow><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></mrow><mo>¯</mo></mover><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>=</mo><mi>C</mi></math>
-<simpara>instead of</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>C</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi><mi>m</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>=</mo><mi>C</mi></math>
-<simpara>or even more complicated with index variables.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Sequences are 1-based, e.g., a sequence <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi></math> with length <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>s</mi><mo>|</mo><mo>=</mo><mi>n</mi></math>, has elements <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>s</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>s</mi><mi>n</mi></msub></math>.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_grammar">
-<title>Grammar</title>
-<section xml:id="_lexical-conventions" role="language-n4js">
-<title>Lexical Conventions</title>
-<simpara>As a super language on top of ECMAScript, the same lexical conventions are supported as described in [<link linkend="ECMA11a">ECMA11a(p.S7)</link>] within strict mode.
-Some further constraints are defined, however, restricting certain constructs. These constraints are described in the following.</simpara>
-<section xml:id="_identifier-names-and-identifiers">
-<title>Identifier Names and Identifiers</title>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S7.6)</link>], [<link linkend="ECMA11a">ECMA11a(p.S11.1.2, p.p.63)</link>] and [<link linkend="ECMA11a">ECMA11a(p.S01.2, p.p.51ff)</link>].</simpara>
-<simpara>As a reminder, identifiers are defined as follows in the ECMAScript specification:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">IdentifierName: IdentifierStart* IdentifierPart;
-IdentifierStart : UnicodeLetter | '_';
- \ UnicodeEscapeSequence</programlisting>
-<simpara>N4JS supports a limited form of computed-names for member declarations:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">N4JSPropertyComputedName:
- '[' (SymbolLiteralComputedName | StringLiteralComputedName) ']'
-;
-
-SymbolLiteralComputedName: N4JSIdentifier '.' N4JSIdentifier ;
-
-StringLiteralComputedName: STRING ;</programlisting>
-<simpara>As can be seen, a computed-name must be either</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a symbol reference, e.g., <literal>Symbol.iterator</literal></simpara>
-</listitem>
-<listitem>
-<simpara>a string literal, i.e., a compile time known constant.
-This notation is useful when interoperating with libraries that define members whose names contain special characters (e.g., a field name starting with commercial-at)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>In N4JS, identifiers are further constrained in order to avoid ambiguities and to make code more readable.
-Some of these constraints will lead to errors, others only to warnings.
-They do not apply for identifiers declared in definitions file (n4jsd) in order to enable declaration of external entities.</simpara>
-<requirement xml:id="IDE-1">
-<title>N4JS Identifier Restrictions</title>
-<simpara>
-<anchor xml:id="Req-IDE-1" xreflabel="[Req-IDE-1]"/>
-<emphasis role="strong">Requirement: IDE-1:</emphasis>
-<link linkend="Req-IDE-1">N4JS Identifier Restrictions</link> (ver. 1)</simpara>
- <simpara>
-
-. If the following constraints do not hold, errors are created.
-.. Leading <literal>$</literal> (dollar sign) character is prohibited for any variable name such as fields, variables, types functions and methods.
-.. Leading <literal>_</literal> (underscore) character is not allowed for identifying any functions or methods.</simpara>
-</requirement>
-<requirement xml:id="IDE-2">
-<title>N4JS identifier recommendations</title>
-<simpara>
-<anchor xml:id="Req-IDE-2" xreflabel="[Req-IDE-2]"/>
-<emphasis role="strong">Requirement: IDE-2:</emphasis>
-<link linkend="Req-IDE-2">N4JS identifier recommendations</link> (ver. 1)</simpara>
- <simpara>
-
-. If the following constraints do not hold, warnings are created.
-. Variable names should, in general, be constructed form the 26 ASCII upper and lower case alphabetic letters (a..z, A..Z), from the 10 decimal digits (0..9) and from the <literal>_</literal> (underscore).
-Although the usage of the international characters are allowed (according to the ECMAScript specification)
-it is discouraged because these characters may not be read or understood well in every circumstance <footnote><simpara><link xl:href="http://javascript.crockford.com/code.html">http://javascript.crockford.com/code.html</link></simpara></footnote>.</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Type (and Type Variable) Identifiers</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">TypeIdentifier: [_A-Z][_a-zA-Z0-9]*
-TypeVariableIdentifier: [_A-Z][_a-zA-Z0-9]*</programlisting>
-</listitem>
-<listitem>
-<simpara>Package Identifiers</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">PackageIdentifier: [_a-z][._a-zA-Z0-9]*; // i.e. the folder names, must not end with .</programlisting>
-</listitem>
-<listitem>
-<simpara>Member Identifiers and Enum Literals</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">InstanceFieldIdentifier: [_a-z][_a-zA-Z0-9]*
-StaticFieldIdentifier: [_A-Z][_A-Z0-9]*([_A-Z0-9]+)*
-EnumLiteral: [_A-Z][_A-Z0-9]*([_A-Z0-9]+)*</programlisting>
-</listitem>
-<listitem>
-<simpara>Variable and Parameter Names</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">VariableIdentifier: [_a-zA-Z0-9]*
-ParameterIdentifier: [_a-z][_a-zA-Z0-9]*</programlisting>
-</listitem>
-<listitem>
-<simpara>Methods</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">MethodIdentifier: [_a-z][_a-zA-Z0-9]*;</programlisting>
-</listitem>
-<listitem>
-<simpara>Annotations</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">AnnotationIdentifier: [_A-Z][_a-zA-Z0-9]*</programlisting>
-</listitem>
-</orderedlist>
-<simpara>The following rules describe how fully qualified names of elements are created.
-Note that these fully qualified names cannot be used in N4JS directly.
-Though they may be shown in error messages etc. to identify elements.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">TypeIdentifier: [A-Z][a-zA-Z0-9]*;
-PackageIdentifier: [a-z][a-zA-Z0-9]*;
-FQNType: (PackageIdentifier '.')+ TypeIdentifier;</programlisting>
-</requirement>
-</section>
-<section xml:id="_this-keyword">
-<title>This Keyword</title>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S11.1.1, p.p.63)</link>]</simpara>
-</section>
-<section xml:id="_regular-expression-literals">
-<title>Regular Expression Literals</title>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S7.8.5)</link>]</simpara>
-</section>
-<section xml:id="_automatic-semicolon-insertion">
-<title>Automatic Semicolon Insertion</title>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S7.9)</link>]</simpara>
-<simpara><link linkend="_acronyms">ASI</link> is supported by the parser, however warnings are issued.</simpara>
-</section>
-<section xml:id="_jsdoc">
-<title>JSDoc</title>
-<simpara>JSDoc are comments similar to JavaDoc in Java for documenting types, functions and members.
-There is no semantic information expressed in JSDoc, that is, the behavior of a program must not change if all the JSDoc is removed.
-The JSDoc tags and overall syntax is a mixture of tags defined by the <link xl:href="https://developers.google.com/closure/compiler/docs/js-for-compiler">Google Closure Compiler</link>, Java’s <link xl:href="http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html">JavaDoc</link> tool and N4-specific tags.</simpara>
-<simpara>JSDoc comments are multiline comments, starting with <literal>/**</literal> (instead of simple multiline comments, starting with <literal>/*</literal>).</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">MultiLineComment: '/*' MultiLineCommentChars? '*/' // from ECMAScript specification
-JSDoc: '/**' MultiLineCommentChars? '*/'</programlisting>
-<simpara>In general, JSDoc comments are placed directly before the annotated language element.
-In some cases, this is slightly different, such as for method parameters, for example, where it is then explicitly specified.</simpara>
-<simpara>The content of JSDoc comments will be covered in more detail in upcoming chapters.
-For documentation purposes, multi- and single-line descriptions are used in several constructs.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">MLVALUE: ([^@]+[^\n]+)+;
-SLVALUE: ([^\n]+);</programlisting>
-<variablelist>
-<varlistentry>
-<term><literal>MLVALUE</literal> </term>
-<listitem>
-<simpara>short for <literal>multi-line value</literal>. This is usually only used for the general description of types or members.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>SLVALUE</literal> </term>
-<listitem>
-<simpara>short for <literal>single-line value</literal>. This is a description which ends at the end of a line.
-It is usually used in combination with other tags, e.g., to further describe a parameter of a method.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_names">
-<title>Names</title>
-<simpara><emphasis>Visibility</emphasis> defines the scope in which a declaration is visible, that is in which context references can be bound to the declaration.
-<emphasis>Access control</emphasis> defines the extent to which types and members are accessible beyond their immediate context.
-Access control may, therefore, restrict the visibility of a declaration by limiting its scope.</simpara>
-<simpara><emphasis>Extensibility</emphasis> refers to whether a given type can be subtyped, or in the case of members, whether they can be overridden.
-Access control is a prerequisite for extensibility which is further explained in <xref linkend="_n4js-specific-classifiers"/></simpara>
-<section xml:id="_access-control" role="language-n4js">
-<title>Access Control</title>
-<simpara>Types from one project may or may not be made accessible to another project.
-Likewise, members from a given type may or may not be made accessible to members existing outside that type.
-For example, if a developer writes an application which uses a library, which types within that library can the application see?
-Given a type that is set as visible, which members of that type can the application see?</simpara>
-<simpara>Accessing a type or member actually means that a reference is bound to a
-declaration with the same identifier.</simpara>
-<simpara>We distinguish the following contexts from which an element is accessed
-as follows:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><emphasis role="strong">Module or type</emphasis>: access from elements in the same module or type.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Subtype</emphasis>: access from a subtype.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Project</emphasis>: access from the same project.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Vendor</emphasis>: access from different project of the same vendor.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">World</emphasis>: access from anything else.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Accessibility is defined by modifiers on types and members, e.g <literal>public</literal>, <literal>protected</literal>, <literal>project</literal>, <literal>private</literal>, via the <literal>export</literal> statement, and by the <literal>@Internal</literal> annotation.
-Extensibility is defined by the <literal>@Final</literal> annotation respectively.</simpara>
-</section>
-<section xml:id="_accessibility-of-types-top-level-variables-and-function-declarations" role="language-n4js">
-<title>Accessibility of Types, Top-Level Variables and Function Declarations</title>
-<simpara>We define types (classes, interfaces, enums) whereby each type has members (fields and methods, depending on the kind of type).
-When we define a type, we need to define whether it is visible only for the specifying module, project or whether that type should be accessible from outside of that project.</simpara>
-<simpara>The same is true for variable declarations and function declarations defined as top-level elements of a module.</simpara>
-<simpara>The following type access modifiers are supported by N4JS:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">enum TypeAccessModifier: project
- | public;</programlisting>
-<simpara>If a type is not exported, its visibility is private.
-If a type has declared visibility <literal>public</literal>, it may additionally be marked as internal via the annotation <literal>@Internal</literal>.
-Thus, we have the following set of type access modifiers:</simpara>
-<simpara>TAM = <literal>private</literal> <literal>project</literal> <literal>public@Internal</literal> <literal>public</literal></simpara>
-<simpara>That is, in N4JS, only the type access modifiers and are available.
-The redundant <literal>project</literal> modifier serves only documentation purpose and can be synthesized if the <literal>export</literal> modifier is preset.</simpara>
-<simpara>All other modifiers used here are synthesized as shown in the next example:</simpara>
-<formalpara>
-<title>Synthesized Type Access Modifiers in N4JS</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class C0 {} // private
-export class C1 {} // project
-export project class C1 {} // project
-export @Internal public class C1 {} // public@Internal
-export public class C2 {} // public
-
-var v0; // private
-export var v1; // project
-export project var v1; // project
-export @Internal public var v3; // public@Internal
-export public var v2; // public
-
-
-function f0() {} // private
-export function f1() {} // project
-export project function f1() {} // project
-export @Internal public function f3() {} // public@Internal
-export public function f2() {} // public</programlisting>
-</para>
-</formalpara>
-<simpara>The access control levels are defined as listed in <xref linkend="tab:type-access-control"/>.</simpara>
-<table xml:id="tab:type-access-control" frame="all" rowsep="1" colsep="1">
-<title>Type Access Control</title>
-<tgroup cols="5">
-<colspec colname="col_1" colwidth="20*"/>
-<colspec colname="col_2" colwidth="20*"/>
-<colspec colname="col_3" colwidth="20*"/>
-<colspec colname="col_4" colwidth="20*"/>
-<colspec colname="col_5" colwidth="20*"/>
-<thead>
-<row>
-<entry align="center" valign="top" namest="col_1" nameend="col_5"><emphasis role="strong">Type Access</emphasis></entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Modifier</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Module</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Project</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Vendor</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">World</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>private</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>project</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>public@Internal</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>public</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara><literal>TAM</literal> is a totally ordered set:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>project</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>public@Internal</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></math>
-<requirement xml:id="IDE-3">
-<title>Type Access Modifiers</title>
-<simpara>
-<anchor xml:id="Req-IDE-3" xreflabel="[Req-IDE-3]"/>
-<emphasis role="strong">Requirement: IDE-3:</emphasis>
-<link linkend="Req-IDE-3">Type Access Modifiers</link> (ver. 1)</simpara>
- <simpara>
-
-The following constraints for type access modifiers for a given type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> (which may be a classifier declaration, a function or a variable) must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>It is an error if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> is not exported but defined as <literal>project</literal>, <literal>public</literal> or <literal>public@Internal</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>It is an error if an annotation <literal>@Internal</literal> is present on a module private or <literal>project</literal> visible type.</simpara>
-</listitem>
-<listitem>
-<simpara>The type modifier for all built-in ECMAScript types is <literal>public</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The <emphasis>default modifier</emphasis> for user declared exported declarations is <literal>project</literal>.
-That is, this modifier is assumed if no modifier is explicitly specified.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<definition>
-<title>Type Accessibility T</title>
-<simpara>
-<anchor xml:id="type_accessibility_t" xreflabel="[type_accessibility_t]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="type_accessibility_t">Type Accessibility T</link></simpara>
-<simpara>
-
-The function <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>α</mi><mi>T</mi></msub><mi>:</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>e</mi><mi>r</mi><mi>e</mi><mi>n</mi><mi>c</mi><mi>e</mi><mo>×</mo><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>⇒</mo><mi>B</mi><mi>o</mi><mi>o</mi><mi>l</mi><mi>e</mi><mi>a</mi><mi>n</mi></math> computes whether a given type, (top-level) variable or function
-reference can access the declaration that it references.
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>α</mi><mi>T</mi></msub></math> is defined with <xref linkend="tab:type-access-control"/>.</simpara>
-<simpara>Formally, we define <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>α</mi><mi>T</mi></msub></math> for a given reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>r</mi></math> and a module top level variable, function or type declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math> as follows <footnote><simpara>See for definitions of metatype properties.</simpara></footnote>:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>D</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></mrow><mrow><msub><mi>α</mi><mi>T</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>D</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public@Internal</mtext></mstyle><mspace width="3.0mm"/><mi>r</mi><mo>.</mo><mi>v</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>o</mi><mi>r</mi><mo>=</mo><mi>D</mi><mo>.</mo><mi>v</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>o</mi><mi>r</mi></mrow><mrow><msub><mi>α</mi><mi>T</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>D</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>project</mtext></mstyle><mspace width="3.0mm"/><mi>r</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi><mo>=</mo><mi>D</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi></mrow><mrow><msub><mi>α</mi><mi>T</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>D</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle><mspace width="3.0mm"/><mi>r</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>=</mo><mi>D</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi></mrow><mrow><msub><mi>α</mi><mi>T</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></mrow></mfrac></math></simpara>
-<simpara>If the type of the arguments is clear from the context, we simply write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>α</mi><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></math> instead of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>α</mi><mi>T</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>D</mi></mfenced></math>.</simpara>
-<simpara>Accessibility for types is only checked for types that manifest themselves in the concrete syntax of the N4JS file.
-Types that do not have to be written to concrete syntax may be used even if they are generally not accessible.
-This is illustrated by <xref linkend="ex:implicit-type-references"/>:</simpara>
-<example xml:id="ex:implicit-type-references">
-<title>Implicit, allowed type references in N4JS</title>
-<programlisting language="n4js" linenumbering="unnumbered">export public class D {
- public takeC(): C { .. }
- public acceptC(c: C): void { .. }
-}
-/* private */ class C {}</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">var d: D = new D()
-d.acceptC( d.takeC() )</programlisting>
-</example>
-</definition>
-<section xml:id="_accessibility-of-members">
-<title>Accessibility of Members</title>
-<simpara>Accessibility at the member level is only applicable when the type itself is accessible.
-If you cannot access the type, you cannot access any of its members.
-Note that inherited members (from an interface or class) become members of a class.
-For example, if <literal>B extends A</literal>, and if <literal>A</literal> is not accessible to some client <literal>C</literal> but <literal>B</literal> is, then the members of <literal>A</literal> are indirectly accessible to <literal>C</literal> in so far as they are accessed via <literal>B</literal>.
-This is true in particular for interfaces, as their properties are possibly merged into the consuming class (cf. <xref linkend="_implementation-of-members"/>).</simpara>
-<simpara>The following member access modifiers are supported by N4JS:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">enum MemberAccessModifier: private
- | project
- | protected
- | public;</programlisting>
-<simpara>The modifiers <literal>protected</literal> and <literal>public</literal> may be annotated with <literal>@Internal</literal>.
-Thus, we can define the following set of member access modifiers:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mi>M</mi><mi>A</mi><mi>M</mi><mo>=</mo><mrow><mo>{</mo><mspace width="3.0mm"/></mrow></mtd></mtr><mtr><mtd><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>protected@Internal</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>protected</mtext></mstyle><mo>,</mo></mtd></mtr><mtr><mtd><mstyle mathvariant="monospace"><mtext>project</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>public@Internal</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></mtd></mtr><mtr><mtd><mrow><mo>}</mo></mrow></mtd></mtr></mtable></math>
-<simpara><literal>protected@Internal</literal> and <literal>public@Internal</literal> are synthesized tags and were introduced as shorthand notation for the <literal>@Internal</literal> annotation together with <literal>protected</literal> or <literal>public</literal> access modifiers.
-The <literal>project</literal> modifier is the default one and it can be omitted.
-As with the type access modifiers, not all member access modifiers are available in N4JS.
-Instead, they are synthesized from different construct as shown in the next example.</simpara>
-<example>
-<title>Synthesized Member Access Modifiers in N4JS</title>
-<programlisting language="n4js" linenumbering="unnumbered">export @Internal public class C {
-
- private f0; // private
- f1; // project
- project f2; // project
- @Internal protected f3; // protected@Internal
- protected f4; // protected
- @Internal public f5; // public@Internal
- public f6; // public
-
- private m0() {} // private
- m1() {} // project
- project m2() {} // project
- @Internal protected m3() {} // protected@Internal
- protected m4() {} // protected
- @Internal public m5() {} // public@Internal
- public m6() {} // public
-}</programlisting>
-</example>
-<simpara><literal>MAM</literal> does not define a totally ordered set. However, its subset</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>M</mi><mi>A</mi><mi>M</mi><mo>\</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>public@Internal</mtext></mstyle></mfenced></math>
-<simpara>is a totally ordered set <footnote><simpara>That is, for application developers not providing a library or a public API available to other vendors, member access modifiers behave almost similar to modifiers known from Java.</simpara></footnote> :</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>project</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>protected@Internal</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>protected</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></math>
-<simpara><xref linkend="tab:Member-Access-Controls"/> shows which members are accessible from where.</simpara>
-<table xml:id="tab:Member-Access-Controls" frame="all" rowsep="1" colsep="1">
-<title>Member Access Control</title>
-<tgroup cols="7">
-<colspec colname="col_1" colwidth="25*"/>
-<colspec colname="col_2" colwidth="12.5*"/>
-<colspec colname="col_3" colwidth="12.5*"/>
-<colspec colname="col_4" colwidth="12.5*"/>
-<colspec colname="col_5" colwidth="12.5*"/>
-<colspec colname="col_6" colwidth="12.5*"/>
-<colspec colname="col_7" colwidth="12.5*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Access Modifier</entry>
-<entry align="center" valign="top">Inside Module</entry>
-<entry align="center" valign="top">Inside Project</entry>
-<entry align="center" valign="top">Vendor</entry>
-<entry align="center" valign="top">Vendor Subtypes</entry>
-<entry align="center" valign="top">Other Projects</entry>
-<entry align="center" valign="top">Everywhere</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><literal>private</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>project</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>protected@Internal</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>protected</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public@Internal</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<definition>
-<title>Type and Member Accessibility Relation</title>
-<simpara>
-<anchor xml:id="type_and_member_accessibility_relation" xreflabel="[type_and_member_accessibility_relation]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="type_and_member_accessibility_relation">Type and Member Accessibility Relation</link></simpara>
-<simpara>
-
-We define the relation</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>=</mo><mspace width="1.0em"/><mi>:</mi><mspace width="1.0em"/><mi>T</mi><mi>A</mi><mi>M</mi><mo>×</mo><mi>M</mi><mi>A</mi><mi>M</mi></math>
-<simpara>as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mo>=</mo><mspace width="1.0em"/><mi>:</mi><mi>:</mi><mo>=</mo><mrow><mo>{</mo></mrow></mtd><mtd><mfenced close=")" open="("><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle></mfenced><mo>,</mo><mfenced close=")" open="("><mstyle mathvariant="monospace"><mtext>project</mtext></mstyle><mstyle mathvariant="monospace"><mtext>project</mtext></mstyle></mfenced><mo>,</mo></mtd></mtr><mtr><mtd/><mtd><mrow><mfenced close=")" open="("><mstyle mathvariant="monospace"><mtext>public@Internal</mtext></mstyle><mstyle mathvariant="monospace"><mtext>public@Internal</mtext></mstyle></mfenced><mo>,</mo><mfenced close=")" open="("><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></mfenced><mo>}</mo></mrow></mtd></mtr></mtable></math>
-<simpara>We further define the relation <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>≥</mo><mi>:</mi><mi>T</mi><mi>A</mi><mi>M</mi><mo>×</mo><mi>M</mi><mi>A</mi><mi>M</mi></math> as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mo>∃</mo><mi>m</mi><mi>a</mi><msup><mi>m</mi><mi>'</mi></msup><mo>∈</mo><mi>M</mi><mi>A</mi><mi>M</mi><mi>:</mi><mi>t</mi><mi>a</mi><mi>m</mi><mo>=</mo><mi>m</mi><mi>a</mi><msup><mi>m</mi><mi>'</mi></msup><mo>∧</mo><mi>m</mi><mi>a</mi><msup><mi>m</mi><mi>'</mi></msup><mo>≥</mo><mi>m</mi><mi>a</mi><mi>m</mi></mrow><mrow><mi>t</mi><mi>a</mi><mi>m</mi><mo>≥</mo><mi>m</mi><mi>a</mi><mi>m</mi></mrow></mfrac></math>
-<simpara>Less, greater then etc. are defined accordingly.</simpara>
-</definition>
-<definition>
-<title>Member Accessibility</title>
-<simpara>
-<anchor xml:id="member_accessibility" xreflabel="[member_accessibility]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="member_accessibility">Member Accessibility</link></simpara>
-<simpara>
-
-The function</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><msub><mi>α</mi><mi>m</mi></msub><mi>:</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>e</mi><mi>r</mi><mi>e</mi><mi>n</mi><mi>c</mi><mi>e</mi><mo>×</mo><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>⇒</mo><mi>B</mi><mi>o</mi><mi>o</mi><mi>l</mi><mi>e</mi><mi>a</mi><mi>n</mi></math>
-<simpara>computes if a given reference can access the member declaration that it
-references.</simpara>
-</definition>
-<simpara>Note that <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>α</mi><mi>m</mi></msub></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi></math> are different functions.
-A reference can only bind to a declaration if it can access the declaration.
-However, bind requires more condition to work (correct metatypes, no shadowing etc).</simpara>
-<simpara>Formally, we define <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>α</mi><mi>m</mi></msub></math> for a given reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>r</mi></math> and member declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math> as follows: <footnote><simpara>See <xref linkend="_n4js-specific-classifiers"/> for definitions of metatype properties. Note that <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>r</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>c</mi><mi>e</mi><mi>i</mi><mi>v</mi><mi>e</mi><mi>r</mi></math> always refers to a type declaration in the context of an expression as the receiver type of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>r</mi></math>. The declaring type of the member declaration is considered to be the receiver type of the member reference rather than the type that originally declares the member declaration.</simpara></footnote> <footnote><simpara>Note the Java-like access restriction for members of visibility <literal role="language-n4js">protected</literal> or <literal role="language-n4js">protected@Internal</literal> to code that is responsible for the implementation of that object. [<link linkend="Gosling15a">Gosling15a(p.S6.6.2, p.p.166)</link>]</simpara></footnote></simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></mrow><mrow><msub><mi>α</mi><mi>m</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>M</mi></mfenced></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>r</mi><mo>.</mo><mi>v</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>o</mi><mi>r</mi><mo>=</mo><mi>M</mi><mo>.</mo><mi>v</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>o</mi><mi>r</mi><mspace width="3.0mm"/><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public@Internal</mtext></mstyle></mrow><mrow><msub><mi>α</mi><mi>m</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>M</mi></mfenced></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>r</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>∈</mo><mi>r</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>c</mi><mi>e</mi><mi>i</mi><mi>v</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><msup><mi>r</mi><mo>*</mo></msup><mspace width="3.0mm"/><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>protected</mtext></mstyle></mrow><mrow><msub><mi>α</mi><mi>m</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>M</mi></mfenced></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>r</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>∈</mo><mi>r</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>c</mi><mi>e</mi><mi>i</mi><mi>v</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><msup><mi>r</mi><mo>*</mo></msup><mspace width="3.0mm"/><mi>r</mi><mo>.</mo><mi>v</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>o</mi><mi>r</mi><mo>=</mo><mi>M</mi><mo>.</mo><mi>v</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>o</mi><mi>r</mi><mspace width="3.0mm"/><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>protected@Internal</mtext></mstyle></mrow><mrow><msub><mi>α</mi><mi>m</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>M</mi></mfenced></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>r</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi><mo>=</mo><mi>M</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi><mspace width="3.0mm"/><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>project</mtext></mstyle></mrow><mrow><msub><mi>α</mi><mi>m</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>M</mi></mfenced></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>r</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>=</mo><mi>r</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mspace width="3.0mm"/><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle></mrow><mrow><msub><mi>α</mi><mi>m</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>M</mi></mfenced></mrow></mfrac></math></simpara>
-<simpara>If the type of the arguments is clear from the context, we simply write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>α</mi><mfenced close=")" open="("><mi>r</mi><mi>M</mi></mfenced></math> instead of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>α</mi><mi>m</mi></msub><mfenced close=")" open="("><mi>r</mi><mi>M</mi></mfenced></math>.</simpara>
-<simpara>Although private members are accessible inside a module, it is not possible to redefine (override etc.) these members (see <xref linkend="_redefinition-of-members"/>).</simpara>
-<requirement xml:id="IDE-4">
-<title>Default Member Access Modifiers</title>
-<simpara>
-<anchor xml:id="Req-IDE-4" xreflabel="[Req-IDE-4]"/>
-<emphasis role="strong">Requirement: IDE-4:</emphasis>
-<link linkend="Req-IDE-4">Default Member Access Modifiers</link> (ver. 1)</simpara>
- <simpara>
-
-The following constraints for member access modifiers must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The <emphasis>default modifier</emphasis> for members of user-declared classes is <literal>project</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The <emphasis>default modifier</emphasis> for members of interfaces is the same as the visibility of the interface itself, except for private interfaces.
-For private interfaces, the default modifier for members is <literal>project</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The modifier for enum literals is always <literal>public</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Private members of a classifier are visible and accessible within a module, i.e. you can access the private method of a class, for instance,
-when the use of the class as receiver is in the same module where the class has been defined.
-In case of inheritance, private members are visible if the host (e.g. the class) is in the same module as the provider (the extended class).
-This also means that abstract members of a class are allowed to be defined private as they may be overridden within a module.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<example>
-<title>Type and Member Access Modifiers</title>
-<programlisting language="n4js" linenumbering="unnumbered">export project interface I {
- project foo();
-}
-
-// This interface may be used publicly, but since the inherited method foo() is project visible only,
-// it is not possible to implement that interface in other projects.
-export public interface J extends I {
-}
-
-// Since the visibility of foo is set to public here, it is possible to implement this interface in other projects.
-export public interface K extends I {
- @Override public foo();
-}
-
-// Since foo is private, it is not possible to subclass the class in other modules. Still, it
-// is possible to use it in other projects.
-// XPECT noerrors -->
-export public abstract class C {
- private abstract foo();
-
- public static C instance() {
- // return some default instance
- ...
- }
-}</programlisting>
-<simpara>As demonstrated in the following snippet, class <literal>C</literal> can be used but not subclassed in other modules:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import C from "C"
-
-// XPECT errors --> "Cannot extend class C: cannot implement one or more non-accessible abstract members: method C.foo." at "C"
-export public abstract class Sub extends C {
-}
-
-// XPECT noerrors -->
-var c: C = C.instance();</programlisting>
-</example>
-<simpara>Members of non-visible types are, in general, not visible for a client.
-Members may become visible, however, if they are accessed via a visible type which inherits these members.
-The following examples demonstrate two different scenarios:</simpara>
-<example>
-<title>Declaring type vs receiver type</title>
-<simpara>It is especially noteworthy that the declaring type of a member is
-generally not considered for the accessibility of that member but only
-the receiver type is relevant.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class Base {
- public m(b: Base): void {}
-}
-export public class ApiType extends Base {
-}</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">import * as N from "Base";
-
-var t = new N.ApiType();
-// member can be accessed although type Base is not exported:
-t.m(t);</programlisting>
-</example>
-<simpara>The property access to the member <literal>m</literal> is valid because it fulfills the constraints for accessibility.
-The receiver of the property access is <literal>t</literal> of type <literal>ApiType</literal>.
-That type is exported and accessible.
-Therefore, the inherited member <literal>m</literal> is also considered valid since it is also defined <literal>public</literal>.</simpara>
-<simpara>This rule allows for defining a common functionality in module or project visible types that becomes accessible via exported, visible subtypes.</simpara>
-<example>
-<title>Member Access and Type Access Interplay</title>
-<simpara>The following example demonstrates the behavior when
-non-visible types are used as return types. In this case, all the
-members of the non-visible types are not accessible, even if they have a
-public access modifier.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- foo(): void{}
-}
-export public class C {
- public getHidden(): A { return new A() };
-}</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">import * as Nfrom "A"
-
-class Client {
- f(): void {
- var c = new N.C();
- // XPECT noerrors --> Getting an instance the hidden type is possible
- var hidden = c.getHidden();
- // XPECT errors --> "The method foo is not visible." at "foo"
- hidden.foo();
- }
-}</programlisting>
-</example>
-</section>
-<section xml:id="_valid-names">
-<title>Valid Names</title>
-<simpara>For identifier and property names, the same constraints as in ECMAScript
-[<link linkend="ECMA11a">ECMA11a(p.S7.6)</link>]
-[<link linkend="ECMA11a">ECMA11a(p.S7.6.1.2)</link>]
-[<link linkend="ECMA11a">ECMA11a(p.S11.6)</link>] are applied.</simpara>
-<simpara>Identifier names in N4JS are defined similar to [<link linkend="ECMA11a">ECMA11a(p.S11.6)</link>], making it possible to even use reserved words (keywords etc.).
-For some element types, errors or warnings are issued in order to prevent problems when using these names.</simpara>
-<requirement xml:id="IDE-5">
-<title>Forbidden Identifier Names in N4JS</title>
-<simpara>
-<anchor xml:id="Req-IDE-5" xreflabel="[Req-IDE-5]"/>
-<emphasis role="strong">Requirement: IDE-5:</emphasis>
-<link linkend="Req-IDE-5">Forbidden Identifier Names in N4JS</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>In N4JS mode, errors are generated in the following cases:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A name of a type equals</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>an access modifier</simpara>
-</listitem>
-<listitem>
-<simpara><literal>set</literal> or <literal>get</literal></simpara>
-</listitem>
-<listitem>
-<simpara>an ECMAScript keyword</simpara>
-</listitem>
-<listitem>
-<simpara>a boolean literal</simpara>
-</listitem>
-<listitem>
-<simpara>the name of a base type</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>The name of a function or function expression equals (but not the method)</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>an ECMAScript keyword</simpara>
-</listitem>
-<listitem>
-<simpara>a reserved future ECMAScript word</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-6">
-<title>Undesired Identifier Names in N4JS</title>
-<simpara>
-<anchor xml:id="Req-IDE-6" xreflabel="[Req-IDE-6]"/>
-<emphasis role="strong">Requirement: IDE-6:</emphasis>
-<link linkend="Req-IDE-6">Undesired Identifier Names in N4JS</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>In N4JS mode, warnings are generated in the following cases:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The name of a member (of a non external type)</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>equals the name of a base type <footnote><simpara><literal role="language-n4js">string, boolean, number, any, null</literal></simpara></footnote> but the type of the variable is different from that type</simpara>
-</listitem>
-<listitem>
-<simpara>is not static nor const but starts with an upper case letter</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>The name of a non-external N4 types (class, interface, enum) starts with a lower case letter</simpara>
-</listitem>
-<listitem>
-<simpara>The name of a variable (incl. formal parameter or catch variable and fields)</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>equals an N4JS keyword</simpara>
-</listitem>
-<listitem>
-<simpara>equals the name of a base type but the type of the variable is different from that type</simpara>
-</listitem>
-<listitem>
-<simpara>is not const but starts with an upper case letter</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="_qualified-names">
-<title>Qualified Names</title>
-<simpara>In N4JS source code, types can only be referenced using their simple name.
-There is no such thing as a fully-qualified type name in N4JS or ECMAScript.
-Types are uniquely identified by their simple name, maybe together with an import and the module specifier given there.
-Clashes between simple names of imported type and locally declared types can be resolved by importing the type under an alias.</simpara>
-<simpara>In some cases, however, we need to define references to types or even members.
-For example, if we want to reference certain members in JSDoc comments or for unambiguous error messages.
-For this reason, we formally define qualified names even if they cannot occur in source code.</simpara>
-<simpara><xref linkend="tab:typenames"/> shows the different names of a given type <literal>C</literal>, defined in a module
-<literal>M.n4js</literal>, defined in a package <literal>p</literal> of a project <literal>MyProject</literal>.</simpara>
-<simpara>Simple type names are used throughout N4JS code in order to refer to types.
-The different forms of module specifiers are only used in import declarations in the string following the <literal>from</literal> keyword.</simpara>
-<table xml:id="tab:typenames" frame="all" rowsep="1" colsep="1">
-<title>Different forms of module and type specifiers.</title>
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="50*"/>
-<colspec colname="col_2" colwidth="50*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Name</entry>
-<entry align="center" valign="top">Example</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara>Simple Type Name</simpara></entry>
-<entry align="center" valign="top"><simpara><literal>C</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>(Plain) Module Specifier</simpara></entry>
-<entry align="center" valign="top"><simpara><literal>p/M</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>Complete Module Specifier</simpara></entry>
-<entry align="center" valign="top"><simpara><literal>MyProject/p/M</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>Complete Type Specifier</simpara></entry>
-<entry align="center" valign="top"><simpara><literal>MyProject/p/M.C</literal></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-</section>
-<section xml:id="_name-duplicates">
-<title>Name Duplicates</title>
-<simpara>There might be cases where two (or more) scopes created by different entities with the same (simple) name overlap.
-Those situations can be referred to as shadowing, hiding, or obscuring.
-While they are not the same, many of those cases are not allowed in N4JS.
-For simplicity we refer to them all as shadowing or duplication (see below).
-Rule of thumb is that N4JS allows everything that is allowed in JavaScript StrictMode.</simpara>
-<section xml:id="_lexical-environment">
-<title>Lexical Environment</title>
-<simpara>N4JS handles scopes similar to ECMAScript, so that function scope is applied to variables declared with <literal>var</literal> (and parameters), and block scope for variables is declared with <literal>let</literal> or <literal>const</literal>.
-In general, ECMAScript defines <emphasis>Lexical Environments</emphasis> as a specification type used to define the association of Identifiers to specific variables and functions based upon the lexical nesting structure of ECMAScript code [<link linkend="ECMA11a">ECMA11a(p.10.2)</link>].</simpara>
-<variablelist>
-<varlistentry>
-<term>Elements that introduce lexical environments: </term>
-<listitem>
-<simpara><literal>FunctionDefinition</literal>, <literal>VariableDeclaration</literal>, <literal>CatchBlock</literal>, <literal>WithStatement</literal>, <literal>ImportDeclaration</literal></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>N4JS specific declarations: </term>
-<listitem>
-<simpara><literal>N4ClassDeclaration</literal>, <literal>N4InterfaceDeclaration</literal>,
-<literal>N4EnumDeclaration</literal>, <literal>N4MethodDeclaration</literal>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Additionally, a built-in lexical environment that defines global scope exists for every <literal>Script</literal>.</simpara>
-<simpara>Since N4JS is extended (and a bit more strict) JS strict mode, <emphasis>Object environment record</emphasis>s created by <literal>WithStatement</literal> are not taken into account when resolving duplicates.
-This applies to both N4JS mode and JS strict mode.
-In unrestricted JS the <literal>WithStatement</literal> is allowed but duplicates are not validated.</simpara>
-<note>
-<simpara>In case of names introduced by <literal>ImportDeclaration</literal>s only <literal>NamedImportSpecifiers</literal>s are taken into account (their import name or its alias if available).
-<literal>WildcardImportSpecifiers</literal>s are not taken into account.
-Potential optimizations by compiler or user annotation are also not currently taken into account during analysis.</simpara>
-</note>
-</section>
-<section xml:id="_duplicates-and-shadowing">
-<title>Duplicates and Shadowing</title>
-<definition>
-<title>Shadowing Overriding Duplicates</title>
-<simpara>
-<anchor xml:id="shadowing_overriding_duplicates" xreflabel="[shadowing_overriding_duplicates]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="shadowing_overriding_duplicates">Shadowing Overriding Duplicates</link></simpara>
-<simpara>
-</simpara>
-<simpara>Two elements with the same name declared in the same lexical environment (cf. [<link linkend="ECMA11a">ECMA11a(p.S10.2.2.1)</link>] are called <emphasis>duplicates</emphasis>.
-An element defined in an environment <emphasis>shadows</emphasis> all elements with the same name in outer environments.</simpara>
-<simpara>In class hierarchies, a member with the same name as a member defined in a supertype is said to override the latter.
-Overriding is discussed in <xref linkend="_redefinition-of-members"/>.</simpara>
-<simpara>For the following constraints, we make the following assumptions:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Names of function expressions or declarations are handles similar to locally declared elements in the function.
-Function declarations are additionally declaring a name in their outer scope.</simpara>
-</listitem>
-<listitem>
-<simpara>The implicit formal parameter <literal>arguments</literal> is treated similar to declared formal parameters.</simpara>
-</listitem>
-<listitem>
-<simpara>Formal parameters are defined in the lexical environment of a function, that is, they are defined in the same lexical environment as local <literal>var</literal>-variables or other declarations in that function.</simpara>
-</listitem>
-<listitem>
-<simpara>The "global" environment contains objects globally defined by the execution environment.</simpara>
-</listitem>
-</itemizedlist>
-</definition>
-<requirement xml:id="IDE-7">
-<title>Forbidden Duplicates</title>
-<simpara>
-<anchor xml:id="Req-IDE-7" xreflabel="[Req-IDE-7]"/>
-<emphasis role="strong">Requirement: IDE-7:</emphasis>
-<link linkend="Req-IDE-7">Forbidden Duplicates</link> (ver. 1)</simpara>
- <simpara>
-
-There must be no two elements defined in the same lexical environment with the same name,
-that is, there must be no duplicates.</simpara>
-</requirement>
-<requirement xml:id="IDE-8">
-<title>Forbidden Shadowing</title>
-<simpara>
-<anchor xml:id="Req-IDE-8" xreflabel="[Req-IDE-8]"/>
-<emphasis role="strong">Requirement: IDE-8:</emphasis>
-<link linkend="Req-IDE-8">Forbidden Shadowing</link> (ver. 1)</simpara>
- <simpara>
-
-In general, shadowing is allowed in N4JS.
-But it is not allowed in the following cases:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>No element defined in the standard global scope must be shadowed.</simpara>
-</listitem>
-<listitem>
-<simpara>There must be no function shadowing another function.</simpara>
-</listitem>
-<listitem>
-<simpara>Elements defined in catch blocks must not shadow elements defined all parent non-catch-block environments.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-9">
-<title>Forbidden Names</title>
-<simpara>
-<anchor xml:id="Req-IDE-9" xreflabel="[Req-IDE-9]"/>
-<emphasis role="strong">Requirement: IDE-9:</emphasis>
-<link linkend="Req-IDE-9">Forbidden Names</link> (ver. 1)</simpara>
- <simpara>
-
-1. In the script environment, it is not allowed to use the name
-’arguments’.<footnote><simpara>This conflicts with the implicit parameter arguments introduced by the transpiler when wrapping the script/module into a definition function.</simpara></footnote></simpara>
-<simpara>+
-<xref linkend="fig-forbidden-shadowing"/> shows nested lexical environments with named elements declared inside (all named <literal>x</literal> here), the forbidden cases are marked with arrows
-(the numbers at the left side refer to the numbers in <xref linkend="Req-IDE-8"/>.</simpara>
-<figure xml:id="fig-forbidden-shadowing">
-<title>Forbidden Shadowing</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/03_names/fig/shadowing.png" width="50%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>shadowing</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Rationale:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>We expect only few named nested functions.
-Since this is expected to be a rare case, no shadowing should occur there as this is maybe not expected by the programmer.</simpara>
-</listitem>
-<listitem>
-<simpara>It is typical that nested environments define local variables.
-In particular helper variables (such as <literal>i: number i</literal> or <literal>s: string</literal> ) are expected to be used quite often.
-Since this is a typical case, we allow shadowing for local variables.</simpara>
-</listitem>
-<listitem>
-<simpara>Function declarations may shadow type declarations.
-However, both entities are to be handled completely differently, so that an error will occur if the shadowing is ignored by the programmer anyway.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-</section>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_types">
-<title>Types</title>
-<section xml:id="_overview" role="language-n4js">
-<title>Overview</title>
-<simpara>N4JS is essentially ECMAScript with the inclusion of types.
-In the following sections we will describe how types are defined and used in N4JS.</simpara>
-<simpara>Besides standard JavaScript types, the following metatypes are introduced:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Classifiers, that is class or interface (see <xref linkend="_classifiers"/>)</simpara>
-</listitem>
-<listitem>
-<simpara>Enum</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Classifiers, methods and functions may be declared generic.</simpara>
-<simpara>Types are related to each other by the subtype relation.</simpara>
-<definition>
-<title>Subtype Relation</title>
-<simpara>
-<anchor xml:id="subtype_relation" xreflabel="[subtype_relation]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="subtype_relation">Subtype Relation</link></simpara>
-<simpara>
-
-We use <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><mi>b</mi><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> for the general subtype relation or type conformance.</simpara>
-<simpara>In nominal typing, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></math> means that <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> is a (transitive) supertype of <emphasis>T</emphasis>.
-Generally in structural typing, this means that <emphasis>T</emphasis> <emphasis>conforms</emphasis> to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math>.
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/></math> is defined transitive reflexive by default.</simpara>
-<simpara>We write <math xmlns="http://www.w3.org/1998/Math/MathML"><mo><</mo></math> to refer to the transitive non-reflexive relation, that is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo><</mo><mi>S</mi><mo>⇔</mo><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi><mo>∧</mo><mi>T</mi><mo>≠</mo><mi>S</mi></math></simpara>
-</definition>
-<simpara>Whether nominal or structural typing is used depends on the declaration of the type or the reference.
-This is explained further in <xref linkend="_structural-typing"/>.</simpara>
-<simpara>For convenience reasons, we sometimes revert the operator, that is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi><mo>⇔</mo><mi>S</mi><mi>:</mi><mo>></mo><mi>T</mi></math>.
-We write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></math> if <emphasis>T</emphasis> is not type conforming to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math>. (cf. [<link linkend="Gosling12a">Gosling12a(p.S4.10)</link>])</simpara>
-<simpara>Join and meet are defined as follows:</simpara>
-<definition>
-<title>Join and Meet</title>
-<simpara>
-<anchor xml:id="join_and_meet" xreflabel="[join_and_meet]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="join_and_meet">Join and Meet</link></simpara>
-<simpara>
-
-A type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> is called a <emphasis>join</emphasis> (or least common supertype, ) of a pair of types <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> and <emphasis>T</emphasis>, written <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo>∨</mo><mi>T</mi><mo>=</mo><mi>J</mi></math>, if</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>J</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>J</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>L</mi><mi>:</mi><mrow><mo>(</mo><mrow><mi>S</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>L</mi><mo>)</mo></mrow><mo>∧</mo><mrow><mo>(</mo><mrow><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>L</mi><mo>)</mo></mrow><mo>→</mo><mi>J</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>L</mi></mrow></mrow></math></simpara>
-<simpara>Similarly, we say that a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math> is a <emphasis>meet</emphasis> (or greatest common subtype, ) of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> and <emphasis>T</emphasis>, written <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo>∧</mo><mi>T</mi><mo>=</mo><mi>M</mi></math>, if<?asciidoc-br?></simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>L</mi><mi>:</mi><mrow><mo>(</mo><mrow><mi>L</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi><mo>)</mo></mrow><mo>∧</mo><mrow><mo>(</mo><mrow><mi>L</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi><mo>)</mo></mrow><mo>→</mo><mi>L</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>M</mi></mrow></mrow></math></simpara>
-</definition>
-<simpara>Note that this declarative definition needs to be specified in detail for special cases, such as union and intersection types.
-Usually, the union type of two types is also the join.</simpara>
-<simpara><xref linkend="fig-cd-predefined-type-hierarchy"/> summarizes all predefined types,
-that is primitive and built-in ECMAScript and N4JS types.
-Specific rules for the subtype relation are defined in the following sections.
-This type hierarchy shows <literal>any</literal> and <literal>undefined</literal> as the top and bottom type (cf. [<link linkend="Pierce02a">Pierce02a(p.15.4)</link>]) We define these types here explicitly:</simpara>
-<definition>
-<title>Top and Bottom Type</title>
-<simpara>
-<anchor xml:id="top_and_bottom_type" xreflabel="[top_and_bottom_type]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="top_and_bottom_type">Top and Bottom Type</link></simpara>
-<simpara>
-
-We call <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mi>o</mi><mi>p</mi></math> the top type, if for all types <emphasis>T</emphasis> the relation <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi><mi>o</mi><mi>p</mi></math> is true.
-We call <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mi>o</mi><mi>t</mi></math> the bottom type, if for all types <emphasis>T</emphasis> the relation <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mi>o</mi><mi>t</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi></math> is true.
-In N4JS, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mi>o</mi><mi>p</mi><mo>=</mo><mi>a</mi><mi>n</mi><mi>y</mi></math>, the bottom type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mi>o</mi><mi>t</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>d</mi><mi>e</mi><mi>f</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi></math>.</simpara>
-</definition>
-<simpara><literal>null</literal> is almost similar to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mi>o</mi><mi>t</mi></math>, except that it is not a subtype of <literal>undefined</literal>.</simpara>
-<figure xml:id="fig-cd-predefined-type-hierarchy">
-<title>Predefined Types Hierarchy</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_types/fig/cdPredefinedTypesHierarchy.svg" width="80%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>cdPredefinedTypesHierarchy</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>For every primitive type there is a corresponding built-in type as defined in [<link linkend="ECMA11a">ECMA11a</link>], e.g. <literal>string</literal> and <literal>String</literal>.
-There is no inheritance supported for primitive types and built-in types – these types are final.</simpara>
-<simpara>Although the diagram shows inheritance between <literal>void</literal> and <literal>undefined</literal>, this relationship is only semantic: <literal>void</literal> is a refinement of <literal>undefined</literal> from a type system viewpoint.
-The same applies to the relation of <literal>Object</literal> as well as the subtypes shown for <literal>string</literal> and <literal>String</literal>.</simpara>
-<example xml:id="ex:class-hierarchy">
-<title>Type Examples, Class Hierarchy</title>
-<simpara>In the following examples, we assume the following classes to be given:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">// C <: B <: A
-class A{}
-class B extends A{}
-class C extends B{}
-
-// independent types X, Y, and Z
-class X{} class Y{} class Z{}
-
-// interfaces I, I1 <: I, I2 <: I, I3
-interface I
-interface I1 extends I {}
-interface I2 extends I {}
-interface I3 {}
-
-// class implementing the interfaces
-class H1 implements I1{}
-class H12 implements I1,I2{}
-class H23 implements I2,I3{}
-
-// a generic class with getter (contra-variance) and setter (co-variance)
-class G<T> {
- get(). T;
- set(x: T): void;
-}</programlisting>
-</example>
-</section>
-<section xml:id="_type-expressions" role="language-n4js">
-<title>Type Expressions</title>
-<simpara>In contrast to ECMAScript, N4JS defines static types.
-Aside from simple type references, type expressions may be used to specify the type of variables.</simpara>
-<section xml:id="_syntax">
-<title>Syntax</title>
-<simpara>The listing <xref linkend="lst:EBNFTypeExpression"/> summarizes the type expression grammar.
-Depending on the context, not all constructs are allowed.
-For example, the variadic modifier is only allowed for function parameters.</simpara>
-<simpara>References to user-declared types are expressed via <literal>ParameterizedTypeRef</literal>.
-This is also true for non-generic types, as the type arguments are optional.
-See <xref linkend="_parameterized-types"/> for details on that reference.</simpara>
-<simpara>For qualified names and type reference names, see <xref linkend="_qualified-names"/></simpara>
-<simpara>The type expressions are usually added to parameter, field, or variable declarations as a suffix, separated with colon (<literal>:</literal>).
-The same is true for function, method, getter or setter return types.
-Exceptions in the cases of object literals or destructuring are explained later on.</simpara>
-<example>
-<title>Type Annotation Syntax</title>
-<simpara>The following two listings show the very same code and type annotations are provided on
-the left hand side. For simplicity, <literal>string</literal> is always used as type expression.<footnote><simpara>In the N4JS IDE, type annotations are highlighted differently than ordinary code.</simpara></footnote></simpara>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="50*"/>
-<colspec colname="col_2" colwidth="50*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var x: string;
-var s: string = "Hello";
-function f(p: string): string {
- return p;
-}
-class C {
- f: string;
- s: string = "Hello";
- m(p: string): string {
- return p;
- }
- get x(): string {
- return this.f;
- }
- set x(v: string) {
- this.f = v;
- }
-}</programlisting></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var x;
-var s = "Hello";
-function f(p) {
- return p;
-}
-class C {
- f;
- s = "Hello";
- m(p) {
- return p;
- }
- get x() {
- return this.f;
- }
- set x(v) {
- this.f = v;
- }
-}</programlisting></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>The code on the right hand side is almost all valid ECMAScript 2015, with the exception of field declarations in the class.
-These are moved into the constructor by the N4JS transpiler.</simpara>
-</example>
-</section>
-<section xml:id="_properties">
-<title>Properties</title>
-<simpara>Besides the properties indirectly defined by the grammar, the following pseudo properties are used for type expressions:</simpara>
-<simpara>Properties of <literal>TypeExpression</literal>:</simpara>
-<variablelist>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi><mi>a</mi><mi>r</mi></math> </term>
-<listitem>
-<simpara>If true, variable of that type is variadic. This is only allowed for parameters. Default value: <literal>false</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>p</mi><mi>t</mi></math> </term>
-<listitem>
-<simpara>If true, variable of that type is optional. This is only allowed for parameters and return types.
-This actually means that the type <emphasis>T</emphasis> actually is a union type of <literal>Undef|<emphasis>T</emphasis></literal>.
-Default value: <literal>false</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>p</mi><mi>t</mi><mi>v</mi><mi>a</mi><mi>r</mi></math> </term>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>p</mi><mi>t</mi><mi>v</mi><mi>a</mi><mi>r</mi><mo>=</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>∨</mo><mi>o</mi><mi>p</mi><mi>t</mi></math>, reflect the facts that a variadic parameter is also optional (as its cardinality is <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mfenced close="]" open="["><mrow><mn>0</mn><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mi>n</mi></mrow></mfenced><mo>)</mo></mrow><mo>.</mo></math></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>n</mi><mi>t</mi><mi>i</mi><mi>t</mi><mi>y</mi></math> </term>
-<listitem>
-<simpara>Pseudo property referencing the variable declaration (or expression) which <literal>owns</literal> the type expression.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_semantics">
-<title>Semantics</title>
-<simpara>The ECMAScript types <emphasis>undefined</emphasis> and <emphasis>null</emphasis> are also supported.
-These types cannot be referenced directly, however.
-Note that <literal>void</literal> and <emphasis>undefined</emphasis> are almost similar.
-Actually, the inferred type of a types element with declared type of <literal>void</literal> will be <emphasis>undefined</emphasis>.
-The difference between void and undefined is that an element of type void can never have another type,
-while an element of type undefined may be assigned a value later on and thus become a different type.
-<literal>void</literal> is only used for function and method return types.</simpara>
-<simpara>Note that not any type reference is allowed in any context.
-Variables or formal parameters must not be declared <literal>void</literal> or union types must not be declared dynamic, for example.
-These constraints are explained in the following section.</simpara>
-<simpara>The types mentioned above are described in detail in the next sections.
-They are hierarchically defined and the following list displays all possible types.
-Note that all types are actually references to types.
-A type variable can only be used in some cases, e.g., the variable has to be visible in the given scope.</simpara>
-<bridgehead xml:id="_ecmascript-types" renderas="sect4">ECMAScript Types</bridgehead>
-<variablelist>
-<varlistentry>
-<term>Predefined Type</term>
-<listitem>
-<simpara>Predefined types, such as String, Number, or Object; and .</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Array Type</term>
-<listitem>
-<simpara><xref linkend="_array-object-type"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Function Type</term>
-<listitem>
-<simpara>Described in <xref linkend="_functions"/>, <xref linkend="_function-type"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Any Type</term>
-<listitem>
-<simpara><xref linkend="_any-type"/>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="_n4types" renderas="sect4">N4Types</bridgehead>
-<variablelist>
-<varlistentry>
-<term>Declared Type</term>
-<listitem>
-<simpara>(Unparameterized) Reference to defined class <xref linkend="_classes"/> or enum <xref linkend="_enums"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Parameterized Type</term>
-<listitem>
-<simpara>Parameterized reference to defined generic class or interface; <xref linkend="_parameterized-types"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>This Type</term>
-<listitem>
-<simpara><xref linkend="_this-type"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Constructor and Type Type</term>
-<listitem>
-<simpara>Class type, that is the meta class of a defined class or interface, <xref linkend="_constructor-and-classifier-type"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Union Types</term>
-<listitem>
-<simpara>Union of types, <xref linkend="_union-type"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Type Variable</term>
-<listitem>
-<simpara>Type variable, <xref linkend="_type-variables"/>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Type expressions are used to explicitly declare the type of a variable, parameter and return type of a function or method, fields (and object literal properties).</simpara>
-</section>
-</section>
-<section xml:id="_type-inference" role="language-n4js">
-<title>Type Inference</title>
-<simpara>If no type is explicitly declared, it is inferred based on the given context, as in the expected type of expressions or function parameters, for example.
-The type inference rules are described in the remainder of this specification.</simpara>
-<definition>
-<title>Default Type</title>
-<simpara>
-<anchor xml:id="default_type" xreflabel="[default_type]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="default_type">Default Type</link></simpara>
-<simpara>
-
-In N4JS mode , if no type is explicitly specified and if no type information can be inferred, <literal>any</literal> is assumed as the default type.</simpara>
-<simpara>In JS mode, the default type is <literal>any+</literal>.</simpara>
-<simpara>Once the type of a variable is either declared or inferred, it is not supposed to be changed.</simpara>
-</definition>
-<simpara>Given the following example.</simpara>
-<formalpara>
-<title>Variable type is not changeable</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">var x: any;
-x = 42;
-x-5; // error: any is not a subtype of number.</programlisting>
-</para>
-</formalpara>
-<simpara>Type of <literal>x</literal> is declared as <literal>any</literal> in line 1. Although a number is assigned to <literal>x</literal> in line 2, the type of <literal>x</literal> is not changed. Thus an error is issued in line 3 because the type of <literal>x</literal> is still <literal>any</literal>.</simpara>
-<simpara role="todo">At the moment, N4JS does not support type guards or, more general, effect system (cf. [<link linkend="Nielson99a">Nielson99a</link>]).</simpara>
-</section>
-<section xml:id="_generic-and-parameterized-types" role="language-n4js">
-<title>Generic and Parameterized Types</title>
-<simpara>Some notes on terminology:</simpara>
-<variablelist>
-<varlistentry>
-<term>Type Parameter vs. Type Argument</term>
-<listitem>
-<simpara>A type parameter is a declaration containing type variables.
-A type argument is a binding of a type parameter to a concrete type or to another type parameter.
-Binding to another type parameter can further restrict the bounds of the type parameter.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>This is similar to function declarations (with formal parameters) and function calls (with arguments).</simpara>
-<section xml:id="_generic-types">
-<title>Generic Types</title>
-<simpara>A class declaration or interface declaration with type parameters declares a generic type.
-A generic type declares a family of types.
-The type parameters have to be bound with type arguments when referencing a generic type.</simpara>
-</section>
-<section xml:id="_type-variables">
-<title>Type Variables</title>
-<simpara>A type variable is an identifier used as a type in the context of a generic class definition, generic interface definition or generic method definition.
-A type variable is declared in a type parameter as follows.</simpara>
-<bridgehead xml:id="_syntax-2" renderas="sect4">Syntax</bridgehead>
-<programlisting language="xtext" linenumbering="unnumbered">TypeVariable:
- (declaredCovariant?='out' | declaredContravariant?='in')?
- name=IdentifierOrThis ('extends' declaredUpperBound=TypeRef)?
-;</programlisting>
-<example>
-<title>Type Variable as Upper Bound</title>
-<simpara>Note that type variables are also interpreted as types.
-Thus, the upper bound of a type variable may be a type variable as shown in the following snippet:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class G<T> {
- <X extends T> foo(x: X): void { }
-}</programlisting>
-</example>
-<bridgehead xml:id="type-variables-properties" renderas="sect4">Properties</bridgehead>
-<simpara>A type parameter defines a type variable, which type may be constrained with an upper bound.</simpara>
-<simpara>Properties of <literal>TypeVariable</literal>:</simpara>
-<variablelist>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math> </term>
-<listitem>
-<simpara>Type variable, as type variable contains only an identifier, we use type parameter instead of type variable (and vice versa) if the correct element is clear from the context.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>U</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi></math> </term>
-<listitem>
-<simpara>Upper bound of the concrete type being bound to this type variable, i.e. a super class.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="type-variables-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-10">
-<title>Type Variable Semantics</title>
-<simpara>
-<anchor xml:id="Req-IDE-10" xreflabel="[Req-IDE-10]"/>
-<emphasis role="strong">Requirement: IDE-10:</emphasis>
-<link linkend="Req-IDE-10">Type Variable Semantics</link> (ver. 1)</simpara>
- <simpara>
-
-1. Enum is not a valid metatype in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>U</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></math>.
-2. Wildcards are not valid in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>U</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></math>.
-3. Primitives are not valid in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>U</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></math>.
-4. Type variables are valid in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>U</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></math>.</simpara>
-</requirement>
-<simpara>A type variable can be used in any type expression contained in the generic class, generic interface, or generic function / method definition.</simpara>
-<example>
-<title>F bounded quantification</title>
-<simpara>Using a type variable in the upper bound reference may lead to recursive definition.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class Chain<C extends Chain<C, T>, T> {
- next() : C { return null; }
- m() : T { return null; }
-}</programlisting>
-</example>
-<bridgehead xml:id="type-variables-type-inference" renderas="sect4">Type Inference</bridgehead>
-<simpara>In many cases, type variables are not directly used in subtype relations as they are substituted with the concrete types specified by some type arguments.
-In these cases, the ordinary subtype rules apply without change.
-However, there are other cases in which type variables cannot be substituted:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Inside a generic declaration.</simpara>
-</listitem>
-<listitem>
-<simpara>If the generic type is used as raw type.</simpara>
-</listitem>
-<listitem>
-<simpara>If a generic function / method is called without type arguments and without the possibility to infer the type from the context.</simpara>
-</listitem>
-</orderedlist>
-<simpara>In these cases, an unbound type variable may appear on one or both sides of a subtype relation and we require subtype rules that take type variables into account.</simpara>
-<simpara>It is important to note that while type variables may have a declared upper bound, they cannot be simply replaced with that upper bound and treated like existential types.
-The following example illustrates this:</simpara>
-<example>
-<title>Type variables vs. existential types</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A {}
-class B extends A {}
-class C extends B {}
-
-class G<T> {}
-
-class X<T extends A, S extends B> {
-
- m(): void {
-
- // plain type variables:
- var t: T;
- var s: S;
-
- t = s; // ERROR: "S is not a subtype of T." at "s" <co xml:id="CO1-1"/>
-
- // existential types:
- var ga: G<? extends A>;
- var gb: G<? extends B>;
-
- ga = gb; <co xml:id="CO1-2"/>
- }
-}</programlisting>
-<calloutlist>
-<callout arearefs="CO1-1">
-<para>Even though the upper bound of <literal>S</literal> is a subtype of <literal>T</literal>’s upper bound (since <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></math>), we cannot infer that <literal>S</literal> is a subtype of <literal>T</literal>,
-because there are valid concrete bindings for which this would not be true: for example, if <literal>T</literal> were bound to <literal>C</literal> and <literal>S</literal> to <literal>B</literal>.</para>
-</callout>
-<callout arearefs="CO1-2">
-<para>This differs from existential types (see <literal>ga</literal> and <literal>gb</literal> and line 21):<?asciidoc-br?>
-<literal>G<? extends B></literal> <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/></math> <literal>G<? extends A></literal> ).</para>
-</callout>
-</calloutlist>
-</example>
-<simpara>We thus have to define subtype rules for type variables, taking the declared upper bound into account.
-If we have a subtype relation in which a type variable appears on one or both sides, we distinguish the following cases:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>If we have type variables on both sides: the result is true if and only if there is the identical type variable on both sides.</simpara>
-</listitem>
-<listitem>
-<simpara>If we have a type variable on the left side and no type variable on the right side:<?asciidoc-br?>
-the result is true if and only if the type variable on the left has one or more declared upper bounds.<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close=")" open="("><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>U</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></mrow></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></math><?asciidoc-br?>
-This is the case for</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close=")" open="("><mrow><mi>T</mi><mspace width="3.0mm"/><mi>e</mi><mi>x</mi><mi>t</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>s</mi><mspace width="3.0mm"/><mi>B</mi></mrow></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></math>
-<simpara>in which T is an unbound type variable and A, B two classes with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>In all other cases the result is false.<?asciidoc-br?>
-This includes cases such as</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mfenced close=")" open="("><mrow><mi>T</mi><mspace width="3.0mm"/><mi>e</mi><mi>x</mi><mi>t</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>s</mi><mspace width="3.0mm"/><mi>A</mi></mrow></mfenced></math>
-<simpara>which is always false, even if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></math> or</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close=")" open="("><mrow><mi>T</mi><mspace width="3.0mm"/><mi>e</mi><mi>x</mi><mi>t</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>s</mi><mspace width="3.0mm"/><mi>A</mi></mrow></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mfenced close=")" open="("><mrow><mi>S</mi><mspace width="3.0mm"/><mi>e</mi><mi>x</mi><mi>t</mi><mi>e</mi><mi>n</mi><mi>d</mi><mi>s</mi><mspace width="3.0mm"/><mi>B</mi></mrow></mfenced></math>
-<simpara>which is always false, even if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>A</mi><mo>=</mo><mi>B</mi></math>.</simpara>
-</listitem>
-</orderedlist>
-<simpara>We thus obtain the following defintion:</simpara>
-<definition>
-<title>Subtype Relation for Type Variables</title>
-<simpara>
-<anchor xml:id="subtype_relation_for_type_variables" xreflabel="[subtype_relation_for_type_variables]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="subtype_relation_for_type_variables">Subtype Relation for Type Variables</link></simpara>
-<simpara>
-
-For two types <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>,</mo><mi>S</mi></math> of which at least one is a type variable, we define</simpara>
-<itemizedlist>
-<listitem>
-<simpara>if both <emphasis>T</emphasis> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> are type variables:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>T</mi><mo>=</mo><mi>S</mi></mrow><mrow><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>if <emphasis>T</emphasis> is a type variable and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> is not:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mrow><mi>T</mi><mo>.</mo><mstyle mathvariant="italic"><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>U</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></mstyle><mo>.</mo><mstyle mathvariant="italic"><mi>s</mi><mi>i</mi><mi>z</mi><mi>e</mi></mstyle><mo>></mo><mn>0</mn></mrow><mrow><mi> </mi><mo>∧</mo><mi> </mi><mo>∀</mo><mi>t</mi><mo>∈</mo><mi>T</mi><mo>.</mo><mstyle mathvariant="italic"><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>U</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></mstyle><mi>:</mi><mi>t</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></mrow></mrow><mrow><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></mrow></mfrac></math>
-</listitem>
-</itemizedlist>
-</definition>
-</section>
-<section xml:id="_parameterized-types">
-<title>Parameterized Types</title>
-<simpara>References to generic types (cf. <xref linkend="_classes"/>) can be parameterized with type arguments.
-A type reference with type arguments is called parameterized type.</simpara>
-<bridgehead xml:id="parameterized-types-syntax" renderas="sect4">Syntax</bridgehead>
-<programlisting language="xtext" linenumbering="unnumbered">ParameterizedTypeRef:
- ParameterizedTypeRefNominal | ParameterizedTypeRefStructural;
-
-ParameterizedTypeRefNominal:
- declaredType=[Type|TypeReferenceName]
- (=> '<' typeArgs+=TypeArgument (',' typeArgs+=TypeArgument)* '>')?;
-
-ParameterizedTypeRefStructural:
- definedTypingStrategy=TypingStrategyUseSiteOperator
- declaredType=[Type|TypeReferenceName]
- (=>'<' typeArgs+=TypeArgument (',' typeArgs+=TypeArgument)* '>')?
- ('with' TStructMemberList)?;
-
-TypeArgument returns TypeArgument:
- Wildcard | TypeRef;
-
-Wildcard returns Wildcard:
- '?'
- (
- 'extends' declaredUpperBound=TypeRef
- | 'super' declaredLowerBound=TypeRef
- )?
-;</programlisting>
-<bridgehead xml:id="parameterized-types-properties" renderas="sect4">Properties</bridgehead>
-<simpara>Properties of parameterized type references (nominal or structural):</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>declaredType</literal> </term>
-<listitem>
-<simpara>Referenced type by type reference name (either the simple name or a qualified name, e.g. in case of namespace imports).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>typeArgs</literal> </term>
-<listitem>
-<simpara>The type arguments, may be empty.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>definedTypingStrategy</literal> </term>
-<listitem>
-<simpara>Typing strategy, by default nominal, see <xref linkend="_structural-typing"/> for details</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>structuralMembers</literal> </term>
-<listitem>
-<simpara>in case of structural typing, reference can add additional members to the structural type, see <xref linkend="_structural-typing"/> for details.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara><emphasis role="strong">Pseudo Properties:</emphasis></simpara>
-<variablelist>
-<varlistentry>
-<term><literal>importSpec</literal> </term>
-<listitem>
-<simpara>The <literal>ImportSpecifier</literal>, may be null if this is a local type reference.
-Note that this may be a <literal>NamedImportSpecifier</literal>. See <xref linkend="_import-statement"/> for details for details.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>moduleWideName</literal> </term>
-<listitem>
-<simpara>Returns simple name of type, that is either the simple name as declared, or the alias in case of an imported type with alias in the import statement.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="parameterized-types-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>The main purpose of a parameterized type reference is to simply refer to the declared type.
-If the declared type is a generic type, the parameterized type references defines a <emphasis>substitution</emphasis> of the type parameters of a generic type with actual type arguments.
-A type argument can either be a concrete type, a wildcard or a type variable declared in the surrounding generic declaration.
-The actual type arguments must conform to the type parameters so that code referencing the generic type parameters is still valid.</simpara>
-<requirement xml:id="IDE-11">
-<title>Parameterized Types</title>
-<simpara>
-<anchor xml:id="Req-IDE-11" xreflabel="[Req-IDE-11]"/>
-<emphasis role="strong">Requirement: IDE-11:</emphasis>
-<link linkend="Req-IDE-11">Parameterized Types</link> (ver. 1)</simpara>
- <simpara>
-
-For a given parameterized type reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi><mo>=</mo><mi>R</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The actual type arguments must conform to the type parameters, that is:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>G</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>=</mo><mo>|</mo><mi>R</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∧</mo><mo>∀</mo><mi> </mi><mi>i</mi><mo>,</mo><mn>0</mn><mo><</mo><mi>i</mi><mo><</mo><mo>|</mo><mi>R</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo><mi>:</mi><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>R</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><mi>g</mi><msub><mi>s</mi><mi>i</mi></msub></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>R</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>i</mi></msub></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>We define type erasure similar to Java [<link linkend="Gosling12a">Gosling12a(p.S4.6)</link>] as 'mapping from types (possibly including parameterized types and type variables)
-to types (that are never parameterized types or type variables)'. We write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math><superscript>o</superscript>
-for the erasure of type <emphasis>T</emphasis>.<footnote><simpara>The notation <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>T</mi><mo>|</mo></math> used in [<link linkend="Gosling12a">Gosling12a</link>] conflicts with the notation of cardinality of sets, which we use in case of union or intersection types for types as well. The notation used here is inspired by [<link linkend="Crary02a">Crary02a</link>], in which a mapping is defined between a typed language <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>λ</mi></math> to an untyped language <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>λ</mi></math><superscript>o</superscript>.</simpara></footnote></simpara>
-<definition>
-<title>Parameterized Type</title>
-<simpara>
-<anchor xml:id="parameterized_type" xreflabel="[parameterized_type]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="parameterized_type">Parameterized Type</link></simpara>
-<simpara>
-
-A parameterized type reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> defines a parameterized type <emphasis>T</emphasis>, in which all type parameters of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> are substituted with the actual values of the type arguments.
-We call the type <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>T</mi><mn>0</mn></msup></math>, in which all type parameters of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> are ignored, the <emphasis>raw type</emphasis> or <emphasis>erasure</emphasis> of <emphasis>T</emphasis>.</simpara>
-<simpara>We define for types in general:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The erasure <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi></math><superscript>o</superscript> of a parameterized type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi><mo><</mo><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>></mo></math> is simply <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>The erasure of a type variable is the erasure of its upper bound.</simpara>
-</listitem>
-<listitem>
-<simpara>The erasure of any other type is the type itself.</simpara>
-</listitem>
-</itemizedlist>
-</definition>
-<simpara>This concept of type erasure is purely defined for specification purposes.
-It is not to be confused with the <literal>real</literal> type erasure which takes place at runtime, in which almost no types (except primitive types) are available.</simpara>
-<simpara>That is, the type reference in <literal>var G<string> gs;</literal> actually defines a type <literal>G<string></literal>, so that <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>g</mi><mi>s</mi></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mo>=</mo><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle><mo>></mo></math>.
-It may reference a type defined by a class declaration <literal>class G<T></literal>.
-It is important that the type <literal>G<string></literal> is different from <literal>G<T></literal>.</simpara>
-<simpara>If a parameterized type reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> has no type arguments, then it is similar to the declared type.
-That is, <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mi>R</mi><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mo>=</mo><mi>T</mi><mo>=</mo><mi>R</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> if (and only if) <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>R</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo><mo>=</mo><mn>0</mn></math>.</simpara>
-<simpara>In the following, we do not distinguish between parameter type reference and parameter type – they are both two sides of the same coin.</simpara>
-<example>
-<title>Raw Types</title>
-<simpara>In Java, due to backward compatibility (generics were only introduced in Java 1.5), it is possible to use raw types in which we refer to a generic type without specifying any type arguments.
-This is not possible in N4JS, as there is no unique interpretation of the type in that case as shown in the following example.
-Given the following declarations:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A{}
-class B extends A{}
-class G<T extends A> { t: T; }
-var g: G;</programlisting>
-</example>
-<simpara>In this case, variable <literal>g</literal> refers to the <emphasis>raw type</emphasis> <literal>G</literal>.
-This is forbidden in N4JS, because two interpretations are possible:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>g</literal> is of type <literal>G<? extends></literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>g</literal> is of type <literal>G<A></literal></simpara>
-</listitem>
-</orderedlist>
-<simpara>In the first case, an existential type would be created, and <literal>g.t = new A();</literal> must fail.</simpara>
-<simpara>In the second case, <literal>g = new G<B>();</literal> must fail.</simpara>
-<simpara>In Java, both assignments work with raw types, which is not really safe.
-To avoid problems due to different interpretations, usage of raw types
-is not allowed in N4JS. <footnote><simpara>Although raw type usage is prohibited, the N4JS validator interprets raw types according to the first case, which may lead to consequential errors.</simpara></footnote></simpara>
-<simpara>Calls to generic functions and methods can also be parameterized, this is described in <xref linkend="_function-calls"/>.
-Note that invocation of generic functions or methods does not need to be parameterized.</simpara>
-<definition>
-<title>Type Conformance</title>
-<simpara>
-<anchor xml:id="type_conformance" xreflabel="[type_conformance]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="type_conformance">Type Conformance</link></simpara>
-<simpara>
-
-We define type conformance for non-primitive type references as follows:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>For two non-parameterized types <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>T</mi><mn>0</mn></msup></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>S</mi><mn>0</mn></msup></math>,</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><msup><mi>S</mi><mn>0</mn></msup><mo>∈</mo><msup><mi>T</mi><mn>0</mn></msup><mo>.</mo><mi>s</mi><mi>u</mi><msup><mi>p</mi><mo>*</mo></msup><mo>∪</mo><msup><mi>T</mi><mn>0</mn></msup><mo>.</mo><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><msup><mi>s</mi><mo>*</mo></msup></mrow><mrow><msup><mi>T</mi><mn>0</mn></msup><mo><</mo><mi>:</mi><msup><mi>S</mi><mn>0</mn></msup></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>For two parameterized types <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo><</mo><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>></mo></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo><</mo><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mi>m</mi></msub><mo>></mo></math></simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><msup><mi>T</mi><mn>0</mn></msup><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><msup><mi>S</mi><mn>0</mn></msup></mrow><mrow><mspace width="10.0em"/><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi><mspace width="10.0em"/></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>(</mo><mi>n</mi><mo>=</mo><mn>0</mn><mo>∨</mo><mi>m</mi><mo>=</mo><mn>0</mn><mo>∨</mo><mrow><mo>(</mo><mi>n</mi><mo>=</mo><mi>m</mi><mo>→</mo><mo>∀</mo><mi>i</mi><mi>:</mi></mrow></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><mrow><msub><mi>T</mi><mi>i</mi></msub><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><msub><mi>S</mi><mi>i</mi></msub><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mrow><mspace width="1.0em"/><mo>∧</mo><mrow><msub><mi>T</mi><mi>i</mi></msub><mo>.</mo><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>:</mi><mo>></mo><msub><mi>S</mi><mi>i</mi></msub><mo>.</mo><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi></mrow><mo>)</mo></mrow><mo>)</mo></mrow><mi>}</mi></math></simpara>
-</listitem>
-</itemizedlist>
-</definition>
-<example>
-<title>Subtyping with parameterized types</title>
-<simpara>Let classes A, B, and C are defined as in the chapter beginning (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></math>).
-The following subtype relations are evaluated as indicated:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">G<A> <: G<B> -> false
-G<B> <: G<A> -> false
-G<A> <: G<A> -> true
-G<A> <: G<?> -> true
-G<? extends A> <: G<? extends A> -> true
-G<? super A> <: G<? super A> -> true
-G<? extends A> <: G<? extends B> -> false
-G<? extends B> <: G<? extends A> -> true
-G<? super A> <: G<? super B> -> true
-G<? super B> <: G<? super A> -> false
-G<? extends A> <: G<A> -> false
-G<A> <: G<? extends A> -> true
-G<? super A> <: G<A> -> false
-G<A> <: G<? super A> -> true
-G<? super A> <: G<? extends A> -> false
-G<? extends A> <: G<? super A> -> false
-G<?> <: G<? super A> -> false
-G<? super A> <: G<?> -> true
-G<?> <: G<? extends A> -> false
-G<? extends A> <: G<?> -> true</programlisting>
-</example>
-<simpara>The figure <xref linkend="cdVarianceChart"/> shows the subtype relations of parameterized types (of a single generic type), which can be used as a cheat sheet.</simpara>
-<figure xml:id="cdVarianceChart">
-<title>Cheat Sheet: Subtype Relation of Parameterized Types</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_types/fig/cdVarianceChart.svg" align="center"/>
-</imageobject>
-<textobject><phrase>cdVarianceChart</phrase></textobject>
-</mediaobject>
-</figure>
-<example>
-<title>Subtyping between different generic types</title>
-<simpara>Let classes <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>H</mi></math> be two generic classes where:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class G<T> {}
-class H<T> extends G<T> {}</programlisting>
-<simpara>Given a simple, non-parameterized class <emphasis>A</emphasis>, the following
-subtype relations are evaluated as indicated:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">G<A> <: G<A> -> true
-H<A> <: G<A> -> true
-G<A> <: H<A> -> false</programlisting>
-</example>
-<bridgehead xml:id="parameterized-types-type-inference" renderas="sect4">Type Inference</bridgehead>
-<simpara>Type inference for parameterized types uses the concept of existential types (in Java, a slightly modified version called capture conversion is implemented).</simpara>
-<simpara>The general concept for checking type conformance and inferring types for generic and parameterized types is described in [<link linkend="Igarashi01a">Igarashi01a</link>] for <emphasis>Featherweight Java with Generics</emphasis>.</simpara>
-<simpara>The concept of existential types with wildcard capture (a special kind of existential type) is published in [<link linkend="Torgersen05a">Torgersen05a</link>], further developed in [<link linkend="Cameron08b">Cameron08b</link>] (further developed in [<link linkend="Cameron09a">Cameron09a</link>] [<link linkend="Summers10a">Summers10a</link>], also see [<link linkend="Wehr08a">Wehr08a</link>] for a similar approach).
-The key feature of the Java generic wildcard handling is called capture conversion, described in [<link linkend="Gosling12a">Gosling12a(p.S5.1.10)</link>].
-However, there are some slight differences to Java 6 and 7, only with Java 8 similar results can be expected.
-All these papers include formal proofs of certain aspects, however even these paper lack proof of other aspect</simpara>
-<simpara>The idea is quite simple: All unbound wildcards are replaced with freshly created new types <footnote><simpara>in the Java 8 spec and compiler, they are called type variables, which are types as well</simpara></footnote>,
-fulfilling the constraints defined by the wildcard’s upper and lower bound.
-These newly created types are then handled similar to real types during type inference and type conformance validation.</simpara>
-<example>
-<title>Existential Type</title>
-<simpara>The inferred type of a variable
-declared as</simpara>
-<simpara><literal>var x: G<? extends A>;</literal>,</simpara>
-<simpara>that is the parameterized type, is an existential type <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>E</mi><mn>1</mn></msub></math>, which is a subtype of A.
-If you have another variable declared as</simpara>
-<simpara><literal>var y: G<? extends A>;</literal></simpara>
-<simpara>another type <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>E</mi><mn>2</mn></msub></math> is created, which is also a subtype of A.
-Note that <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>E</mi><mn>1</mn></msub><mo>≠</mo><msub><mi>E</mi><mn>2</mn></msub></math>! Assuming typical setter or getter in G, e.g. <literal>set(T t)</literal> and <literal>T get()</literal>, the following code snippet will produce an error:</simpara>
-<simpara><literal>y.set(x.get())</literal></simpara>
-<simpara>This is no surprise, as <literal>x.get()</literal> actually returns a type <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>E</mi><mn>1</mn></msub></math>, which is not a subtype of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>E</mi><mn>2</mn></msub></math>.</simpara>
-</example>
-<simpara>The upper and lower bound declarations are, of course, still available during type inference for these existential types.
-This enables the type inferencer to calculate the join and meet of parameterized types as well.</simpara>
-<requirement xml:id="IDE-12">
-<title>Join of Parameterized Types</title>
-<simpara>
-<anchor xml:id="Req-IDE-12" xreflabel="[Req-IDE-12]"/>
-<emphasis role="strong">Requirement: IDE-12:</emphasis>
-<link linkend="Req-IDE-12">Join of Parameterized Types</link> (ver. 1)</simpara>
- <simpara>
-
-The join of two parameterized types <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi><mo><</mo><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>></mo></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>H</mi><mo><</mo><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mi>m</mi></msub><mo>></mo></math> is the join of the raw types, this join is then parameterized with the join of the
-upper bounds of of type arguments and the meet of the lower bounds of the type arguments.</simpara>
-<simpara>For all type rules, we assume that the upper and lower bounds of a non-generic type, including type variables,
-simply equal the type itself, that is for a given type <emphasis>T</emphasis>, the following constraints hold:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mi>T</mi></math></simpara>
-</requirement>
-<example>
-<title>Upper and lower bound of parameterized types</title>
-<simpara>Assuming the given classes listed above, the following upper and lower bounds are expected:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">G<A> -> upperBound = lowerBound = A
-G<? extends A> -> lowerBound = null, upperBound = A
-G<? super A> -> lowerBound = A, upperBound = any
-G<?> -> lowerBound = null, upperBound = any</programlisting>
-<simpara>This leads to the following expected subtype relations:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">(? extends A) <: A -> true
-(? super A) <: A -> false
-A <: (? extends A) -> false
-A <: (? super A) -> true</programlisting>
-</example>
-<simpara>Note that there is a slight difference to Java: In N4JS it is not possible to use a generic type in a raw fashion, that is to say without specifying any type arguments.
-In Java, this is possible due to backwards compatibility with early Java versions in which no generics were supported.</simpara>
-<simpara>In case an upper bound of a type variable shall consist only of a few members, it seems convenient to use additional structural members,
-like on interface I2 in the example <xref linkend="ex:use-declared-interfaces-for-lower-bounds"/> below.
-However, type variables must not be constrained using structural types (see constraint <xref linkend="Req-IDE-76"/>).
-Hence, the recommended solution is to use an explicitly declared interface that uses definition site structural typing for these constraints as an upper bound (see interface in <xref linkend="ex:use-declared-interfaces-for-lower-bounds"/>).</simpara>
-<example xml:id="ex:use-declared-interfaces-for-lower-bounds">
-<title>Use declared interfaces for lower bounds</title>
-<programlisting language="n4js" linenumbering="unnumbered">interface I1<T extends any with {prop : int}> { // error
-}
-
-interface ~J {
- prop : int;
-}
-interface I2<T extends J> {
-}</programlisting>
-</example>
-</section>
-</section>
-<section xml:id="_primitive-ecmascript-types" role="language-n4js">
-<title>Primitive ECMAScript Types</title>
-<simpara>N4JS provides the same basic types as ECMAScript [<link linkend="ECMA11a">ECMA11a(p.p.28)</link>].</simpara>
-<note>
-<simpara>In ECMAScript, basic types come in two flavors: as primitive types [<link linkend="ECMA11a">ECMA11a(p.S8Types, p.p.28)</link>] and as Objects [<link linkend="ECMA11a">ECMA11a(p.S15, p.p.102)</link>].
-In N4JS, primitive types are written with lower cases, object types with first case capitalized.
-For example, <literal>String</literal> is the primitive ECMAScript string type, while <literal>String</literal> is an object.</simpara>
-</note>
-<simpara>The following ECMAScript primitive types are supported, they are written
-with lower case letters::</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>undefined</literal>: [<link linkend="ECMA11a">ECMA11a(p.S8.3)</link>]; cannot be used in type expression, see void below.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>null</literal> [<link linkend="ECMA11a">ECMA11a(p.S8.3)</link>]; cannot be used in type expression</simpara>
-</listitem>
-<listitem>
-<simpara><literal>boolean</literal> [<link linkend="ECMA11a">ECMA11a(p.S8.3)</link>]</simpara>
-</listitem>
-<listitem>
-<simpara><literal>string</literal> [<link linkend="ECMA11a">ECMA11a(p.S8.4)</link>]</simpara>
-</listitem>
-<listitem>
-<simpara><literal>number</literal> [<link linkend="ECMA11a">ECMA11a(p.S8.5)</link>]</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Although Object is a primitive type in [<link linkend="ECMA11a">ECMA11a(p.S8.5)</link>], it is interpreted here as an object type and described in <xref linkend="_object-type"/>.</simpara>
-<simpara>Please note that primitive types are values (= no objects) so they have no properties and you cannot inherit from them.</simpara>
-<section xml:id="_undefined-type">
-<title>Undefined Type</title>
-<simpara>As a built-in type, the type <literal>undefined</literal> cannot be declared explicitly by the user by means of a type expression.
-Note in ECMAScript there are three distinct use cases of <literal>undefined</literal>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>undefined</literal> as type (as used here)</simpara>
-</listitem>
-<listitem>
-<simpara><literal>undefined</literal> as value (the only value of the undefined type)</simpara>
-</listitem>
-<listitem>
-<simpara><literal>undefined</literal> is a property of the global object with undefined (value) as initial value.
-Since ECMAScript 5 it is not allowed to reassign this property but this is not enforced by all ECMAScript/JavaScript engines.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The type <literal>undefined</literal> will be inferred to false in a boolean expression.
-It is important to note that something that is not assigned to a value is <literal>undefined</literal> but not <literal>null</literal>.</simpara>
-<simpara>The type <literal>undefined</literal> is a subtype of all types. That is,</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>undefined</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi></mrow></mfrac></math>
-<simpara>is an axiom and true for all types <emphasis>T</emphasis>.</simpara>
-<simpara>Whenever an expression <emphasis>E</emphasis> has an inferred type of <literal>undefined</literal>, which means it will always evaluate to
-value <literal>undefined</literal> at runtime, a warning is shown, unless <emphasis>E</emphasis> is …​</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a <literal>void</literal> expression</simpara>
-</listitem>
-<listitem>
-<simpara>the direct child expression of a <literal>void</literal> expression,</simpara>
-</listitem>
-<listitem>
-<simpara>the direct child expression of an expression statement,</simpara>
-</listitem>
-<listitem>
-<simpara>the <literal>undefined</literal> literal (i.e. the literal representing the <literal>undefined</literal> value),</simpara>
-</listitem>
-<listitem>
-<simpara>the <literal>this</literal> literal.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_null-type">
-<title>Null Type</title>
-<simpara>The <literal>null</literal> type cannot be declared explicitly by the user. Only the keyword <literal>null</literal> is inferred to type <literal>null</literal>.</simpara>
-<bridgehead xml:id="null-type-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>In contrast to <literal>undefined</literal>, it expresses the intentional absence of a value.</simpara>
-<simpara>The <literal>null</literal> type can be assigned to any other type.
-That is, the type <literal>null</literal> is a subtype of all other types except <literal>undefined</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>undefined</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle><mi> </mi><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>Type</mtext></mstyle><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></mfrac></math>
-<simpara>Please note that</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>null==undefined</literal> evaluates to <literal>true</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>null===undefined</literal> evaluates to <literal>false</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>typeof null</literal> evaluates to <literal>object</literal></simpara>
-</listitem>
-</itemizedlist>
-<simpara>Only the <literal>null</literal> keyword is inferred to type null. If <literal>null</literal> is assigned to a variable, the type of the variable is not changed.
-This is true, in particular, for variable declarations.
-For example in</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var x = null;</programlisting>
-<simpara>the type of variable <literal>x</literal> is inferred to <literal>any</literal> (cf. <xref linkend="_variable-statement"/>).</simpara>
-<simpara>The type <literal>null</literal> will be inferred to false in a boolean expression.</simpara>
-<simpara>The call <literal>typeof null</literal> will return ’object’.</simpara>
-</section>
-<section xml:id="_primitive-boolean-type">
-<title>Primitive Boolean Type</title>
-<simpara>Represents a logical entity having two values, true and false.</simpara>
-<simpara>Please note that a boolean primitive is coerced to a number in a comparison operation so that</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="66.6666*"/>
-<colspec colname="col_2" colwidth="33.3334*"/>
-<thead>
-<row>
-<entry align="center" valign="top">Source</entry>
-<entry align="center" valign="middle">Result</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var a = true; console.log(a == 1)</programlisting></entry>
-<entry align="center" valign="middle"><simpara><emphasis role="strong">prints true</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var b = false; console.log(b == 0)</programlisting></entry>
-<entry align="center" valign="middle"><simpara><emphasis role="strong">prints true</emphasis></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<bridgehead xml:id="primitive-boolean-type-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>The type <literal>boolean</literal> is subtype of <literal>any</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>boolean</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac><mrow/></math>
-<simpara>Variables of type <literal>boolean</literal> can be auto-converted (coerced) to <literal>Boolean</literal>, as described in <xref linkend="_autoboxing-and-coercing"/>.</simpara>
-</section>
-<section xml:id="_primitive-string-type">
-<title>Primitive String Type</title>
-<simpara>A finite sequence of zero or more 16-bit unsigned integer values (elements).
-Each element is considered to be a single UTF-16 code unit.</simpara>
-<simpara>Also string as primitive type has no properties, you can access the properties available on the object String as string will be coerced to String on the fly
-but just for that property call, the original variable keeps its type:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var a = "MyString"
-console.log(typeof a) // string
-console.log(a.length) // 8
-console.log(typeof a) // string</programlisting>
-<simpara>You can handle a primitive <literal>string</literal> like an object type <literal>String</literal> but with these exceptions:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>typeof "MyString"</literal> is <literal>'string'</literal> but <literal>typeof new String("MyString")</literal> is <literal>'object'</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>"MyString" instanceof String</literal> or <literal>instanceof Object</literal> will return <literal>false</literal>, for <literal>new String("MyString")</literal> both checks evaluate to <literal>true</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>console.log(eval("2+2"))</literal> returns <literal>4</literal>, <literal>console.log(eval(new String("2+2")))</literal> returns string <literal>"2+2"</literal></simpara>
-</listitem>
-</itemizedlist>
-<simpara>This marks a difference to Java.
-In JavaScript, Unicode escape sequences are never interpreted as a special character.</simpara>
-<bridgehead xml:id="primitive-string-type-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>The <literal>string</literal> type is a subtype of <literal>any</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac><mrow/></math>
-<simpara>It is supertype of the N4JS primitive type <literal>pathselector</literal>, <literal>typeName</literal> and <literal>i18nKey</literal>.
-<xref linkend="_primitive-pathselector-and-i18nkey"/></simpara>
-<simpara>However, variables of type <literal>string</literal> can be auto-converted (coerced) to <literal>string</literal>, as described in <xref linkend="_autoboxing-and-coercing"/>.</simpara>
-</section>
-<section xml:id="_primitive-number-type">
-<title>Primitive Number Type</title>
-<simpara>In ECMAScript numbers are usually 64-bit floating point numbers.
-For details see [<link linkend="ECMA11a">ECMA11a(p.8.5)</link>].
-The prefix <literal>0</literal> indicates that the number is octal-based and the prefix <literal>0x</literal> marks it as hexadecimal-based.</simpara>
-<simpara><literal>NaN</literal> can be produced by e.g. ‘0 / 0’' or ‘1 - x’. <literal>typeof NaN</literal> will return <literal>number</literal>.</simpara>
-<bridgehead xml:id="primitive-number-type-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>The type <literal>number</literal> is subtype of <literal>any</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac><mrow/></math>
-<simpara>However, variables of type <literal>number</literal> can be auto-converted (coerced) to <literal>Number</literal>, as described in <link linkend="_integer-literals">Integer Literals</link> .</simpara>
-</section>
-<section xml:id="_primitive-type-int">
-<title>Primitive Type int</title>
-<simpara>Actually ECMAScript defines an internal type <literal>int32</literal>.
-A number of this type is returned by the binary or operation using zero as operand, e.g. ECMAScript’s internal type int32 can be represented in N4JS by a built-in primitive type called <literal>int</literal>.
-For details on how numeric literals map to types <literal>number</literal> and <literal>int</literal>, refer to <xref linkend="_integer-literals"/>.</simpara>
-<important>
-<simpara>for the time being, built-in type <literal>int</literal> is synonymous to type <literal>number</literal>.
-This means one can be assigned to the other and a value declared to be of type <literal>int</literal> may actually be a 64-bit floating
-point number.<footnote><simpara>The rationale for having this limited implementation of type is that API designers already want to start providing hints where later only 32-bit integers will be used. For the time being, <emphasis role="strong">this is checked neither statically nor at runtime</emphasis>!</simpara></footnote></simpara>
-</important>
-</section>
-<section xml:id="_primitive-symbol-type">
-<title>Primitive Symbol Type</title>
-<simpara>The primitive type <literal>symbol</literal> is directly as in ECMAScript 6.
-Support for symbols is kept to a minimum in N4JS. While this primitive type can be used without any restrictions, the only value of this type available in N4JS is the built-in symbol <literal>Symbol.iterator</literal>.
-Other built-in symbols from ECMAScript 6 and the creation of new symbols are not supported.
-For more details, see <xref linkend="_symbol"/>.</simpara>
-</section>
-</section>
-<section xml:id="_primitive-n4js-types" role="language-n4js">
-<title>Primitive N4JS Types</title>
-<simpara>Additionally to the primitive ECMAScript types, the following N4JS-specific primitive types are supported:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>any</literal></term>
-<listitem>
-<simpara>enables ECMAScript-like untyped variable declarations</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>void</literal></term>
-<listitem>
-<simpara>almost similar to undefined, except it can be used as a return type of functions and methods</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>unknown</literal></term>
-<listitem>
-<simpara>inferred in case of a type inference error</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>pathSelector<T></literal>, <literal>i18nKey</literal></term>
-<listitem>
-<simpara>subtypes of string</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<section xml:id="_any-type">
-<title>Any Type</title>
-<simpara>Any type is the default type of all variables for without a type declaration.
-It has no properties.
-A value of any other type can be assigned to a variable of type <literal>any</literal>, but a variable declared <literal>any</literal> can only be assigned to another variable declared with the type <literal>any</literal>.</simpara>
-<section xml:id="any-type-semantics">
-<title>Semantics</title>
-<simpara><literal>any</literal> is supertype of all other types. That is,</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>Type</mtext></mstyle><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mrow><mi>a</mi><mi>n</mi><mi>y</mi></mrow></mrow></mfrac></math>
-<simpara>is an axiom and true for all types.</simpara>
-</section>
-<section xml:id="any-type-type-inference">
-<title>Type Inference</title>
-<simpara>If a variable is explicitly declared as type <literal>any</literal>, the inferred type of that variable will always be <literal>any</literal>.</simpara>
-<section xml:id="_default-type-of-variables">
-<title>Default Type of Variables</title>
-<simpara>If a type annotation is missing and no initializer is provided, then the type of a variable is implicitly set to <literal>any</literal>.</simpara>
-<simpara>In that case, the inferred type of that variable will always be <literal>any</literal> as well.
-If an initializer is provided, the declared type of the variable will be set to the inferred type of the initializer.
-Therefore in the latter case, the inferred type of the variable will always be the type of the initializer (cf. <xref linkend="_variable-statement"/>).</simpara>
-<simpara>If a variable is declared as type , it can be used just as every variable can be used in raw ECMAScript.
-Since every property can be get and set, the types of properties is inferred as as well.
-This is formally expressed in <xref linkend="_identifier"/>.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_void-type">
-<title>Void Type</title>
-<simpara>The type <literal>void</literal> is used to denote that there is no value at all, as opposed to type
-<literal>undefined</literal> which denotes that there is a value, but it is always undefined.</simpara>
-<simpara>The only valid use of type <literal>void</literal> is to declare that a function or method does not
-return anything. In particular, this means:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>void</literal> is disallowed as type argument,</simpara>
-</listitem>
-<listitem>
-<simpara><literal>void</literal> is disallowed as upper/lower bound of type parameters and wild cards,</simpara>
-</listitem>
-<listitem>
-<simpara>when used as return type of functions or methods, <literal>void</literal> may not be nested, i.e.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">function foo(): void {} // ok
-function bar(): any|void {} // error</programlisting>
-</listitem>
-</itemizedlist>
-<simpara>In all the above disallowed cases, type <literal>undefined</literal> should be used instead of <literal>void</literal>.</simpara>
-<section xml:id="void-type-semantics">
-<title>Semantics</title>
-<requirement xml:id="IDE-13">
-<title>Void Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-13" xreflabel="[Req-IDE-13]"/>
-<emphasis role="strong">Requirement: IDE-13:</emphasis>
-<link linkend="Req-IDE-13">Void Type</link> (ver. 1)</simpara>
- <simpara>
-
-* The type <literal>void</literal> may only be used as the immediate return type of a function or method.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If a function <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> is declared to return <literal>void</literal>, an error is created if a return statement contains an expression:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle><mo>→</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>r</mi><mo>,</mo><mi>μ</mi><mfenced close=")" open="("><mi>r</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>ReturnStatement</mtext></mstyle><mo>,</mo><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>=</mo><mi>f</mi><mi>:</mi><mi>r</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara>If a function <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> is declared to return <literal>void</literal>, an error is issued if the function is called in any statement or expression but an expression statement directly:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle><mo>→</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>e</mi><mo>,</mo><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mi>e</mi><mi>f</mi></mfenced><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mrow><mi>e</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>ExpressionStatement</mtext></mstyle></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>The following type hierarchy is defined: <literal>void</literal> is only a subtype of itself but not of any other type and no other type is a subtype of void.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle></mrow></mfrac></math>
-<simpara>Since <literal>void</literal> cannot be used as the type of variables, fields, formal parameters, etc., a
-function or method with a return type of void cannot be used on the right-hand side of
-an assignment or in the argument list of a call expression (note the difference to plain
-JavaScript).</simpara>
-<simpara>The ECMAScript <literal>void</literal> operator (see <link linkend="_unary-expression">Unary Expressions</link>) has a type
-of <literal>undefined</literal>, not <literal>void</literal>, because it evaluates to value <literal>undefined</literal> and can be used
-on the right-hand side of assignments, etc.</simpara>
-</section>
-</section>
-<section xml:id="_unknown-type">
-<title>Unknown Type</title>
-<simpara>Internally N4JS defines the type <literal>unknown</literal>.
-This type cannot be used by the user.
-Instead, it is inferred in case of errors.
-<literal>unknown</literal> behaves almost similar to <literal>any+</literal>.
-However no error messages once a variable or expression has been inferred to <literal>unknown</literal> in order to avoid consequential errors.</simpara>
-</section>
-<section xml:id="_primitive-pathselector-and-i18nkey">
-<title>Primitive Pathselector and I18nKey</title>
-<simpara>N4JS introduces three new types which are subtypes of string.
-These types are, in fact, translated to strings and do not add any new functionality.
-They are solely defined for enabling additional validation.</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>pathSelector<T></literal> is a generic type for specifying path selector expressions. PathSelectors are used to specify a path to a property in a (JSON-like) model tree.</simpara>
-</listitem>
-<listitem>
-<simpara>The type variable <literal>T</literal> defines the context type (or type of the root of the tree) in which the selector is to be validated.
-A path selector is defined as a string literal that has to conform to the path selector grammar.
-The context type is then used to perform a semantic</simpara>
-</listitem>
-<listitem>
-<simpara><literal>i18nKey</literal> is a string which refers to an internationalization key.
-The <literal>i18nKey</literal> type is used to reference resource keys specified in resource files.
-In a project <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi></math>, the <literal>i18nKey</literal> type defines the transitive set of all resource keys accessible from <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi></math>.
-Since resource keys are specified as strings, this means that the <literal>i18nKey</literal> type defines a subset of all string literals that can be assigned to a variable of type <literal>i18nKey</literal> in the current project.
-That means that an assignment of a string literal to a variable of type <literal>i18nKey</literal> is only valid if that string literal is contained in the set defined by <literal>i18nKey</literal>.
-Resource keys are declared in the properties files of a project and all resource keys from a project are accessible to any project depending on it.</simpara>
-</listitem>
-</itemizedlist>
-<simpara role="todo">I18nkeys are not yet validated</simpara>
-<section xml:id="pathselector-semantics">
-<title>Semantics</title>
-<simpara>The N4JS primitive types <literal>pathSelector<T></literal>, <literal>i18nKey</literal> and <literal>pathSelector<T></literal> are basically only marker types of strings for enabling additional validation.
-Thus, they are completely interchangeable with string types:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>typeName</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mo>></mo><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac><mspace width="3.0mm"/><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>typeName</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mo>></mo></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>i18nKey</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac><mspace width="3.0mm"/><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>i18nKey</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>pathSelector</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mo>></mo><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac><mspace width="3.0mm"/><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>pathSelector</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mo>></mo></mrow></mfrac></math></simpara>
-<simpara>As special literals for these N4JS types do not exist, the type has to be explicitly specified in order to enable the additional validation.
-Note that this validation cannot be applied for more complicated expressions with parts which cannot be evaluated at compile time.
-For example, <literal>"some.path."segment".prop"</literal> cannot be evaluated at compile time.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_built-in-ecmascript-object-types" role="language-n4js">
-<title>Built-in ECMAScript Object Types</title>
-<simpara>N4JS supports all built-in ECMAScript objects [<link linkend="ECMA11a">ECMA11a(p.S15)</link>], interpreted as classes.
-Some of these object types are object versions of primitive types.
-The object types have the same name as their corresponding primitive type, but start with an upper case letter.</simpara>
-<simpara>The following types, derived from certain ECMAScript predefined objects and constructs, are supported by means of built-in types as they are required by certain expressions.</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>Object</literal> [<link linkend="ECMA11a">ECMA11a(p.p.111)</link>];</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Function</literal> [<link linkend="ECMA11a">ECMA11a(p.p.117)</link>]; representing functions and function objects <xref linkend="_function-type"/> but also methods (<xref linkend="_methods"/>)</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Array</literal> [<link linkend="ECMA11a">ECMA11a(p.p.122)</link>], representing array objects, see <xref linkend="_array-object-type"/></simpara>
-</listitem>
-<listitem>
-<simpara><literal>String</literal> [<link linkend="ECMA11a">ECMA11a(p.p.141)</link>]</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Boolean</literal> [<link linkend="ECMA11a">ECMA11a(p.p.141)</link>]</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Number</literal> [<link linkend="ECMA11a">ECMA11a(p.p.141)</link>]</simpara>
-</listitem>
-<listitem>
-<simpara><literal>RegExp</literal> [<link linkend="ECMA11a">ECMA11a(p.p.180)</link>]; they can be constructed by means of special literals (cf. <xref linkend="_literals"/>)</simpara>
-</listitem>
-<listitem>
-<simpara>global object type</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Symbol</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>Promise</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>Iterator</literal> and <literal>Iterable</literal></simpara>
-</listitem>
-</itemizedlist>
-<simpara>All other ECMAScript types ([<link linkend="ECMA11a">ECMA11a(p.S15)</link>], such as <literal>Math</literal>, <literal>Date</literal>, or <literal>Error</literal> are supported by means of predefined classes.
-ECMAScript 2015 types are defined in the ECMAScript 2015 runtime environment.
-Since they are defined and used similar to user defined classes, they are not explained in further detail here.
-These predefined objects are kind of subtypes of <literal>Object</literal>.</simpara>
-<section xml:id="ECMAScript-objects-semantics">
-<title>Semantics</title>
-<simpara>It is not possible to inherit from any of the built-in ECMAScript object types except for <literal>Object</literal> and <literal>Error</literal>, that is,
-to use one of these types as supertype of a class.
-From the N4JS language’s point of view, these built-in types are all final.</simpara>
-</section>
-<section xml:id="_object-type">
-<title>Object Type</title>
-<simpara><literal>Object</literal> [<link linkend="ECMA11a">ECMA11a(p.S8.6)</link>] is the (implicit) supertype of all declared (i.e., non-primtive) types, including native types.
-It models the ECMAScript type <literal>Object</literal>, except that no properties may be dynamically added to it.
-In order to declare a variable to which properties can be dynamically added, the type <literal>Object+</literal> has to be declared
-(cf. <xref linkend="_type-modifiers"/>).</simpara>
-</section>
-<section xml:id="_function-object-type">
-<title>Function-Object-Type</title>
-<simpara>The built-in object type <literal>Function</literal>, a subtype of <literal>Object</literal>, represents all functions, regardless of how they are defined (either via function expression,
-function declaration, or method declaration).
-They are described in detail in <xref linkend="_function-object-type"/>.</simpara>
-<simpara>Since <literal>Function</literal> is the supertype of all functions regardless of number and types of formal parameters, return type, and number and bounds of type parameters,
-it would not normally be possible to invoke an instance of <literal>Function</literal>.
-For the time being, however, an instance of <literal>Function</literal> can be invoked, any number of arguments may be provided and the invocation may be parameterized with any number of
-type arguments (which will be ignored), i.e. <xref linkend="Req-IDE-101"/> and <xref linkend="Req-IDE-102"/> do not apply.</simpara>
-</section>
-<section xml:id="_array-object-type">
-<title>Array Object Type</title>
-<simpara>The <literal>Array</literal> type is generic with one type parameter, which is the item type. An array is accessed with the index operator, the type of the index parameter is <literal>Number</literal>.
-The type of the stored values is <emphasis>typeArgs[0]</emphasis> (cf. <xref linkend="_array-literal"/>). Due to type erasure, the item type is not available during runtime,
-that is to say there are no reflective methods returning the item type of an array.</simpara>
-<requirement xml:id="IDE-14">
-<title>Array Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-14" xreflabel="[Req-IDE-14]"/>
-<emphasis role="strong">Requirement: IDE-14:</emphasis>
-<link linkend="Req-IDE-14">Array Type</link> (ver. 1)</simpara>
- <simpara>
-
-For an array type <emphasis>A</emphasis>, the following conditions must be true:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>A</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo><mo>=</mo><mn>1</mn></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-</section>
-<section xml:id="_string-object-type">
-<title>String Object Type</title>
-<simpara>Object type version of <literal>string</literal>. It is highly recommend to use the primitive version only.
-Note that is is not possible to assign a primitive typed value to an object typed variable.</simpara>
-</section>
-<section xml:id="_boolean-object-type">
-<title>Boolean Object Type</title>
-<simpara>Object type version of <literal>boolean</literal>. It is highly recommend to use the primitive version only.
-Note that is is not possible to assign a primitive typed value to an object typed variable.</simpara>
-</section>
-<section xml:id="_number-object-type">
-<title>Number Object Type</title>
-<simpara>Object type version of <literal>number</literal>. It is highly recommend to use the primitive version only.
-Note that is is not possible to assign a primitive typed value to an object typed variable.</simpara>
-</section>
-<section xml:id="_global-object-type">
-<title>Global Object Type</title>
-<simpara>This is the globally accessible namespace which contains element such as undefined, and in case of browsers, window. Depending on the runtime environment,
-the global object may has different properties defined by means of dynamic polyfills.</simpara>
-</section>
-<section xml:id="_symbol">
-<title>Symbol</title>
-<simpara>The symbol constructor function of ECMAScript 2015. Support for symbols
-is kept to a minimum in N4JS:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>creating symbols with <literal>var sym = Symbol("description")</literal> is not supported.</simpara>
-</listitem>
-<listitem>
-<simpara>creating shared symbols with <literal>var sym = Symbol.for("key")</literal> is not supported.
-Also the inverse <literal>Symbol.keyFor(sym)</literal> is not supported.</simpara>
-</listitem>
-<listitem>
-<simpara>retrieving built-in symbols via properties in <literal>Symbol</literal> is supported, however, the only built-in symbol available in N4JS is the iterator symbol that can be retrieved with <literal>Symbol.iterator</literal>.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The rationale for this selective support for symbols in N4JS is to allow for the use (and custom definition) of iterators and iterables and their application in the <literal>for…​of</literal>
-loop with as little support for symbols as possible.</simpara>
-</section>
-<section xml:id="_promise">
-<title>Promise</title>
-<simpara><literal>Promise</literal> is provided as a built-in type as in ECMAScript 2015.
-Also see <xref linkend="_asynchronous-functions"/> for asynchronous functions.</simpara>
-</section>
-<section xml:id="_iterator-interface">
-<title>Iterator Interface</title>
-<simpara>A structurally typed interface for <emphasis>iterators</emphasis> as defined by theECMAScript 6 iterator protocol.</simpara>
-<formalpara>
-<title>Iterable in N4JS</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">// providedByRuntime
-export public interface ~Iterator<T> {
- public next(): IteratorEntry<T>
-}
-
-// providedByRuntime
-export public interface ~IteratorEntry<T> {
- public done: boolean;
- public value: T?;
-}</programlisting>
-</para>
-</formalpara>
-<simpara role="todo">Interface <literal>IteratorEntry</literal> was introduced mainly as a workaround; this interface could be removed and replaced with a corresponding
-structural type reference as return type of method <literal>next()</literal></simpara>
-</section>
-<section xml:id="_iterable-interface">
-<title>Iterable Interface</title>
-<simpara>A structurally typed interface for objects that can be iterated over, i.e. <emphasis>iterables</emphasis> as defined by the ECMAScript 6 iterator protocol.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">// providedByRuntime
-export public interface ~Iterable<T> {
- public [Symbol.iterator](): Iterator<T>
-}</programlisting>
-<simpara>Note that this interface’s method is special in that a symbol is used as identifier.
-You can use the ordinary syntax for computed property names in ECMAScript 6 for overriding / implementing or invoking this method.</simpara>
-</section>
-</section>
-<section xml:id="_built-in-n4js-types" role="language-n4js">
-<title>Built-In N4JS Types</title>
-<simpara>N4JS additionally provides some built-in classes which are always available with the need to explicitly import them.</simpara>
-<section xml:id="_n4object">
-<title>N4Object</title>
-<simpara>Although <literal>N4Object</literal> is a built-in type, it is not the default supertype.
-It is a subtype of <literal>Object</literal>.</simpara>
-<section xml:id="N4Object-semantics">
-<title>Semantics</title>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>Object</mtext></mstyle></mrow></mfrac></math>
-</section>
-</section>
-<section xml:id="_n4class">
-<title>N4Class</title>
-<simpara>The type <literal>N4Class</literal> is used for extended reflection in N4JS.</simpara>
-<simpara role="todo">Add further docs for this type</simpara>
-</section>
-<section xml:id="IterableN">
-<title>IterableN</title>
-<simpara role="todo">Work in progress.</simpara>
-<simpara>Currently there are built-in types <literal>Iterable2<T1,T2></literal>…​<literal>Iterable9<T1,…​,T9></literal>.
-They are mainly intended for type system support of array destructuring literals.</simpara>
-<note>
-<simpara>This is not documented in detail yet, because we want to gain experience with the current solution first, major refinement may be incoming.</simpara>
-</note>
-</section>
-</section>
-<section xml:id="_type-modifiers" role="language-n4js">
-<title>Type Modifiers</title>
-<simpara>Type expressions can be further described with type modifiers.
-The type modifiers add additional constraints to the type expression which are then used to perform a stricter validation of the source code.
-Type modifiers can not be used in type arguments.</simpara>
-<simpara>The general type modifiers <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mi>o</mi><mi>n</mi><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi><mi>y</mi><mi>n</mi><mi>a</mi><mi>m</mi><mi>i</mi><mi>c</mi></math> can be used for variables, attributes, method parameters and method types.
-Optional and variadic modifiers can only be applied for formal parameters.</simpara>
-<section xml:id="Type_Modifiers_Dynamic">
-<title>Dynamic</title>
-<simpara>The dynamic type modifier marks a type as being dynamic.
-A dynamic type behaves like a normal JavaScript object, so you can read/write any property and call any method on it.
-The default behavior for a type is to be static, that is no new properties can be added and no unknown properties can be accessed.</simpara>
-<simpara><literal>T</literal> <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/></math> <literal>T+</literal> and <literal>T+</literal> <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/></math> <literal>T</literal> is always true.
-Using dynamically added members of a dynamic type is never type safe.
-Using the <literal>delete</literal> operator on a subtype of <literal>N4Object</literal> is not allowed.</simpara>
-<requirement xml:id="IDE-15">
-<title>Non-Dynamic Primitive Types</title>
-<simpara>
-<anchor xml:id="Req-IDE-15" xreflabel="[Req-IDE-15]"/>
-<emphasis role="strong">Requirement: IDE-15:</emphasis>
-<link linkend="Req-IDE-15">Non-Dynamic Primitive Types</link> (ver. 1)</simpara>
- <simpara>
-
-1. All primitive types except <literal>any</literal> must not be declared dynamic.
-2. Only parameterized type references and this type reference can be declared dynamic.<footnote><simpara>This is a consequence of the syntax definition.</simpara></footnote></simpara>
-</requirement>
-</section>
-<section xml:id="_optional-return-types">
-<title>Optional Return Types</title>
-<simpara>Only formal parameters and return types can be marked as optional.</simpara>
-<simpara>An optional return type indicates that the function / method need not be left via a return statement with an expression; in that case the return value is <literal>undefined</literal>.
-For constraints on using the optional modifier, see <xref linkend="_function-object-type"/>.</simpara>
-</section>
-</section>
-<section xml:id="_union-and-intersection-type-composed-types" role="language-n4js">
-<title>Union and Intersection Type (Composed Types)</title>
-<simpara>Given two or more existing types, it is possible to compose a new type by forming either the union or intersection of the base types.
-The following example gives a small overview of common use cases of union and intersection types.</simpara>
-<example>
-<title>Composed types</title>
-<simpara>This example shows how union and intersection types affect the types of their field members in case the fields have different types.
-It is for illustration purposes only.
-The type of the composed field depends on the access type:
-When reading, the field type of an intersection/union also resolves to the intersection/union.
-In contrast, when writing a field, the field type of an intersection/union resolves to the union/intersection respectively.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface A { f : int = 1; }
-interface B { f : string = "h"; }
-
-class CA implements A {}
-class CB implements B {}
-
-let aub : A|B; // union type
-let aib : A&B; // intersection type
-
-function u() {
- aub = (catIsAlive)? new CA() : new CB(); // catIsAlive is boolean
- let x = aub.f; // x = {1 | "h"}
- aub.f = undefined; // undefined can be assigned to int and string types
-}
-function i() {
- let a = aib as A;
- let b = aib as B;
- a.f = 23;
- b.f = "text";
- let x = aib.f; // x = {23 & "text"} which is impossible
-}
-// type of 'aub.f' --> int|string
-let fu = aub.f;
-// type of 'aub.f' --> int&string
-aub.f = undefined;
-// type of 'aib.f' --> int&string
-let fi = aib.f;
-// type of 'aib.f' --> int|string
-aib.f = undefined;</programlisting>
-<simpara>Note that no instance <literal>aib</literal> of intersection type <literal>A&B</literal> can be instantiated, since the instance’s class would have to define a field <literal>f</literal> which would have to comply to both of the interfaces <literal>A</literal> and <literal>B</literal>.
-Still the function <literal>i()</literal> shows in general how variables of intersection types can be casted and accessed.</simpara>
-</example>
-<simpara>The following sections define these <emphasis>union</emphasis> and <emphasis>intersection types</emphasis> in detail.</simpara>
-<section xml:id="_union-type">
-<title>Union Type</title>
-<simpara>Union type reflect the dynamic nature of JavaScript. Union types can be used almost everywhere (e.g., in variable declarations or in formal method parameters).
-The type inferencer usually avoids returning union types and prefers single typed joins or meets.
-<emphasis>The most common use case for union types is for emulating method overloading</emphasis>, as
-we describe later on.<footnote><simpara>For type theory about union types, [<link linkend="Pierce02a">Pierce02a(p.15.7)</link>] and [<link linkend="Igarashi07a">Igarashi07a</link>], other languages that explicitly support the notion of union type include Ceylon [<link linkend="King13a">King13a(p.3.2.4/5)</link>]</simpara></footnote></simpara>
-<section xml:id="union-type-syntax">
-<title>Syntax</title>
-<simpara>For convenience, we repeat the definition of union type expression:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">UnionTypeExpression: 'union' '{' typeRefs+=TypeRefWithoutModifiers (',' typeRefs+=TypeRefWithoutModifiers)* '}';</programlisting>
-</section>
-<section xml:id="union-type-semantics">
-<title>Semantics</title>
-<simpara>An union type states that the type of a variable may be one or more types contained in the union type.
-In other words, a union type is a kind of type set, and the type of a variable is contained in the type set.
-Due to interfaces, a variable may conform to multiple types.</simpara>
-<requirement xml:id="IDE-18">
-<title>Union Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-18" xreflabel="[Req-IDE-18]"/>
-<emphasis role="strong">Requirement: IDE-18:</emphasis>
-<link linkend="Req-IDE-18">Union Type</link> (ver. 1)</simpara>
- <simpara>
-
-For a given union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><msub><mi>T</mi><mn>1</mn></msub><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><msub><mi>T</mi><mi>n</mi></msub></mfenced></math>, the following conditions must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Non-empty: At least one element has to be specified:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>≠</mo><mi>∅</mi></math> (<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mi>n</mi><mo>≥</mo><mn>1</mn><mo>)</mo></mrow></math></simpara>
-</listitem>
-<listitem>
-<simpara>Non-dynamic: The union type itself must not be declared dynamic:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><mi>U</mi><mo>.</mo><mi>d</mi><mi>y</mi><mi>n</mi><mi>a</mi><mi>m</mi><mi>i</mi><mi>c</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Non-optional elements:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>T</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>→</mo><mo>¬</mo><mi>T</mi><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></math></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-19">
-<title>Union Type Subtyping Rules</title>
-<simpara>
-<anchor xml:id="Req-IDE-19" xreflabel="[Req-IDE-19]"/>
-<emphasis role="strong">Requirement: IDE-19:</emphasis>
-<link linkend="Req-IDE-19">Union Type Subtyping Rules</link> (ver. 1)</simpara>
- <simpara>
-
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi></math> be an union type.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The union type is a common supertype of all its element types:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>T</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi></mrow><mrow><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>U</mi></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>More generally, a type is a subtype of a union type, if it is a
-subtype of at least one type contained in the union:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mo>∃</mo><mi>T</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>S</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi></mrow><mrow><mi>S</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>U</mi></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>A union type is a subtype of a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math>, if all types of the union are subtypes of that type.
-This rule is a generalization of the sub typing rules given in [<link linkend="Igarashi07a">Igarashi07a(p.p.40)</link>]</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mo>∀</mo><mi>T</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></mrow><mrow><mi>U</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>Commutativity: The order of element does not matter:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>A</mi><mo>,</mo><mi>B</mi></mrow></mfenced><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>B</mi><mo>,</mo><mi>A</mi></mrow></mfenced></math>
-</listitem>
-<listitem>
-<simpara>Associativity:
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>A</mi><mo>,</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>B</mi><mo>,</mo><mi>C</mi></mrow></mfenced></mrow></mfenced><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>A</mi><mo>,</mo><mi>B</mi></mrow></mfenced><mo>,</mo><mi>C</mi></mrow></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara>Uniqueness of elements: A union type may not contain duplicates
-(similar to sets):</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mn>1</mn><mo>≤</mo><mi>i</mi><mo><</mo><mi>k</mi><mo>≤</mo><mi>n</mi><mo>,</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced><mi>:</mi><msub><mi>T</mi><mi>i</mi></msub><mo>≠</mo><msub><mi>T</mi><mi>k</mi></msub></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-20">
-<title>Implicit simplification of union types</title>
-<simpara>
-<anchor xml:id="Req-IDE-20" xreflabel="[Req-IDE-20]"/>
-<emphasis role="strong">Requirement: IDE-20:</emphasis>
-<link linkend="Req-IDE-20">Implicit simplification of union types</link> (ver. 1)</simpara>
- <simpara>
-
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi></math> be an union type.
-The following simplification rules are always automatically applied to union types.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Simplification of union type with one element:
-If a union type contains only one element, it is reduced to the element:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mi>T</mi></mfenced></mrow><mi>T</mi></mfrac></math>
-</listitem>
-<listitem>
-<simpara>Simplification of union types of union types:
-A union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi></math> containing another union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>V</mi></math> is reduced to a single union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>W</mi></math>, with
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>W</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>=</mo><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>∪</mo><mi>V</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi></math>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></msub><mo>,</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>m</mi></msub></mrow></mfenced><mo>,</mo><msub><mi>S</mi><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mi>n</mi></msub></mrow></mfenced></mrow><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></msub><mo>,</mo><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>m</mi></msub><mo>,</mo><msub><mi>S</mi><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mi>n</mi></msub></mrow></mfenced></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>Simplification of union type with undefined or null:
-Since undefined is the bottom type, and null is kind of a second button type, they are removed from the union:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></msub><mo>,</mo><msub><mi>T</mi><mi>k</mi></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced></mrow><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></msub><mo>,</mo><mi>u</mi><mi>n</mi><mi>d</mi><mi>e</mi><mi>f</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi></mrow></mfenced><mo>,</mo><msub><mi>T</mi><mi>k</mi></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></msub><mo>,</mo><msub><mi>T</mi><mi>k</mi></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced></mrow><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></msub><mo>,</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></mrow></mfenced><mo>,</mo><msub><mi>T</mi><mi>k</mi></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfrac></math></simpara>
-</listitem>
-</itemizedlist>
-<note>
-<simpara>Simplification rules for union types with one element are applied first.</simpara>
-</note>
-<itemizedlist>
-<listitem>
-<simpara>The structural typing strategy is propagated to the types of the union:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>~</mi><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced></mrow><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>~</mi><msub><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mn>1</mn></msub><mo>,</mo><mi>…</mi><mo>,</mo><mi>~</mi><msub><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mi>n</mi></msub></mrow></mfenced></mrow></mfrac></math>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>Remarks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The simplification rules may be applied recursively.</simpara>
-</listitem>
-<listitem>
-<simpara>For given types <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></math>, and the union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>A</mi><mo>,</mo><mi>B</mi></mrow></mfenced></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>≠</mo><mi>B</mi></math>.
-The types are equivalent, however: <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>A</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mo>=</mo><mi>U</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mo>=</mo><mi>A</mi></math>.<footnote><simpara>This is different from Ceylon ( [<link linkend="King13a">King13a(p.3.2.3)</link>]), in which the union is defined to be <literal>the same type as</literal> <emphasis>A</emphasis>. Although the meaning of <literal>same</literal> is not clear, it is possibly used as a synonym for <literal>equivalent</literal>.</simpara></footnote></simpara>
-</listitem>
-</itemizedlist>
-<example>
-<title>Subtyping with union type</title>
-<simpara>Let A, B, and C be defined as in the chapter beginning (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>B</mi><mo><</mo><mi>:</mi><mi>A</mi></math>)</simpara>
-<simpara>The following subtyping relations with union types are to be evaluated as follows: <footnote><simpara>See Example <xref linkend="ex:class-hierarchy"/> for class definitions.</simpara></footnote></simpara>
-<programlisting language="n4js" linenumbering="unnumbered">A <: union{A} -> true
-A <: union{A,B} -> true
-B <: union{A,B} -> true
-C <: union{A,B} -> true
-A <: union{B,C} -> false
-B <: union{B,C} -> true
-C <: union{B,C} -> true
-union{A} <: A -> true
-union{B} <: A -> true
-union{B,C} <: A -> true
-union{A,B} <: B -> false
-union{X,Z} <: union{Z,X} -> true
-union{X,Y} <: union{X,Y,Z} -> true
-union{X,Y,Z} <: union{X,Y} -> false</programlisting>
-</example>
-<simpara>The simplification constraints are used by the type inferrer.
-It may be useful, however, to define union types with superfluous elements, as the next example demonstrates</simpara>
-<example>
-<title>Superfluous elements in union type</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A{}
-class B extends A{}
-class C extends A{}
-
-function foo(p: union{A,B}) {..}</programlisting>
-</example>
-<simpara>Although <literal>B</literal> is superfluous, it may indicate that the function handles parameters of type differently than one of type <literal>A</literal> or <literal>C</literal>.</simpara>
-<simpara>Although a union type is a <literal><link linkend="_acronyms">LCST</link></literal> of its contained (non-superfluous) types, the type inferrer usually does not create new union types when computing the join of types.
-If the join of types including at least one union type is calculated, the union type is preserved if possible.
-The same is true for meet.</simpara>
-<simpara>For the definition of join and meet for union types, we define how a type is added to a union type:</simpara>
-<requirement xml:id="IDE-21">
-<title>Union of union type</title>
-<simpara>
-<anchor xml:id="Req-IDE-21" xreflabel="[Req-IDE-21]"/>
-<emphasis role="strong">Requirement: IDE-21:</emphasis>
-<link linkend="Req-IDE-21">Union of union type</link> (ver. 1)</simpara>
- <simpara>
-
-The union of union types is defined similar to the union of sets.
-The union is not simplified, but it contains no duplicates.</simpara>
-<simpara>If a type A is contained in a union type, then the union type is a common supertype, and (since it is the union itself) also the <literal><link linkend="_acronyms">LCST</link></literal> of both types.
-This finding is the foundation of the definition of join of a (non-union) type with a union type:</simpara>
-</requirement>
-<requirement xml:id="IDE-22">
-<title>Join with Union Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-22" xreflabel="[Req-IDE-22]"/>
-<emphasis role="strong">Requirement: IDE-22:</emphasis>
-<link linkend="Req-IDE-22">Join with Union Type</link> (ver. 1)</simpara>
- <simpara>
-
-The join <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> of a union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi></math> with a type <emphasis>T</emphasis> is the union of both types:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>J</mi><mo>=</mo><mi>U</mi><mo>∪</mo><mi>T</mi></mrow><mrow><mfenced close=")" open="("><mrow><mi>U</mi><mo>∨</mo><mi>T</mi></mrow></mfenced><mo>=</mo><mi>J</mi></mrow></mfrac></math>
-<simpara>Remarks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Joining a union type with another type is not similar to joining the elements of the union type directly with another type.
-That is</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>A</mi><mspace width="3.0mm"/><mstyle mathvariant="bold"><mi>j</mi><mi>o</mi><mi>i</mi><mi>n</mi></mstyle><mspace width="3.0mm"/><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>B</mi><mo>,</mo><mi>C</mi></mrow></mfenced><mo>≠</mo><mi>A</mi><mspace width="3.0mm"/><mstyle mathvariant="bold"><mi>j</mi><mi>o</mi><mi>i</mi><mi>n</mi></mstyle><mspace width="3.0mm"/><mi>B</mi><mspace width="3.0mm"/><mstyle mathvariant="bold"><mi>j</mi><mi>o</mi><mi>i</mi><mi>n</mi></mstyle><mspace width="3.0mm"/><mi>C</mi></math>
-</listitem>
-<listitem>
-<simpara>The computed join is simplified according to the constraints defined above.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-23">
-<title>Meet with Union Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-23" xreflabel="[Req-IDE-23]"/>
-<emphasis role="strong">Requirement: IDE-23:</emphasis>
-<link linkend="Req-IDE-23">Meet with Union Type</link> (ver. 1)</simpara>
- <simpara>
-
-The meet of union types is defined as the meet of the elements.
-That is</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>∧</mo><mi>S</mi><mo>∧</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>∧</mo><msub><mi>T</mi><mi>n</mi></msub><mo>∧</mo><mi>S</mi></mrow><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced><mo>∧</mo><mi>S</mi></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>∧</mo><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mn>1</mn></msub><mo>∧</mo><msub><mi>S</mi><mi>m</mi></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>∧</mo><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>∧</mo><msub><mi>S</mi><mi>m</mi></msub></mrow><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced><mo>∧</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mi>m</mi></msub></mrow></mfenced></mrow></mfrac></mtd></mtr></mtable></math>
-<simpara>Remarks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The meet of a union type with another type is not a union type itself.
-This gets clear when looking at the definition of meet and union type.
-While for a given <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>A</mi><mo>,</mo><mi>B</mi></mrow></mfenced></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>A</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>U</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>U</mi></math>, the opposite <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></math> is usually not true (unless <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi></math> can be simplified to <emphasis>A</emphasis>).
-So, for <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>A</mi><mo>∧</mo><mi>U</mi></math>, usually <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi></math> cannot be the meet.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-24">
-<title>Upper and Lower Bound of a Union Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-24" xreflabel="[Req-IDE-24]"/>
-<emphasis role="strong">Requirement: IDE-24:</emphasis>
-<link linkend="Req-IDE-24">Upper and Lower Bound of a Union Type</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>The upper and lower bound of a union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi></math> is a union type <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>U</mi><mi>'</mi></msup></math> containing the upper and lower bound of the elements of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi></math>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced></mrow></mfenced><mi>:</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>T</mi><mn>1</mn></msub></mfenced><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>T</mi><mn>1</mn></msub></mfenced></mrow></mfenced></mtd></mtr><mtr><mtd><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mrow><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced></mrow></mfenced><mi>:</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>T</mi><mn>1</mn></msub></mfenced><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>T</mi><mn>1</mn></msub></mfenced></mrow></mfenced></mtd></mtr></mtable></math>
-</requirement>
-</section>
-<section xml:id="_warnings">
-<title>Warnings</title>
-<simpara>In case the <literal>any</literal> type is used in a union type, all other types in the union type definition become obsolete.
-However, defining other typers along with the <literal>any</literal> type might seem reasonable in case those other types are treated specifically and thus are mentioned explicitly in the definition.
-Nevertheless the use of the <literal>any</literal> type produces a warning, since its use can indicate a misunderstanding of the union type concept and since documentation can also be done in a comment.</simpara>
-<requirement xml:id="IDE-25">
-<title>Any type in union types</title>
-<simpara>
-<anchor xml:id="Req-IDE-25" xreflabel="[Req-IDE-25]"/>
-<emphasis role="strong">Requirement: IDE-25:</emphasis>
-<link linkend="Req-IDE-25">Any type in union types</link> (ver. 1)</simpara>
- <simpara>
-
-No union type shall conatin an type:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∄</mo><mi>a</mi><mi>n</mi><mi>y</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi></math>
-<simpara>Similar to the documentary purpose of using specific classes along with the <literal>any</literal> type is the following case.
-When two types are used, one of them a subtype of the other, then this subtype is obsolete. Still it can be used for documentary purposes.
-However, a warning will be produced to indicate unecessary code.
-The warning is only produced when both of the types are either classes or interfaces, since e.g. structural types are supertypes of any classes or interfaces.</simpara>
-</requirement>
-<requirement xml:id="IDE-26">
-<title>Redundant subtypes in union types</title>
-<simpara>
-<anchor xml:id="Req-IDE-26" xreflabel="[Req-IDE-26]"/>
-<emphasis role="strong">Requirement: IDE-26:</emphasis>
-<link linkend="Req-IDE-26">Redundant subtypes in union types</link> (ver. 1)</simpara>
- <simpara>
-
-Union types shall not
-contain class or interface types which are a subtype of another class or interface type that also is contained in the union type.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mo>∄</mo><mi>T</mi><mi>T</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mo>∃</mo><mi>T</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi></mtd></mtr><mtr><mtd><mrow><mo>(</mo><mrow><mi>T</mi><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi><mo>∧</mo><mi>i</mi><mi>s</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mi>O</mi><mi>r</mi><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∧</mo><mi>i</mi><mi>s</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mi>O</mi><mi>r</mi><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mfenced close=")" open="("><mrow><mi>T</mi><mi>T</mi></mrow></mfenced><mo>)</mo></mrow></mrow></mtd></mtr></mtable></math>
-</requirement>
-</section>
-</section>
-<section xml:id="_intersection-type">
-<title>Intersection Type</title>
-<simpara>Intersection type reflects the dynamic nature of JavaScript, similar to union type.
-As in Java, intersection type is used to define the type boundaries of type variables in type parameter definitions.
-They are inferred by the type inferencer for type checking (as a result of join or meet).
-In contrast to Java, however, intersection type can be declared explicitly by means of intersection type expression.<footnote><simpara>For type theory about intersection types, see [<link linkend="Pierce02a">Pierce02a(p.15.7)</link>] and [<link linkend="Laurent12a">Laurent12a</link>], other languages supporting explicit notion of intersection type include Ceylon [<link linkend="King13a">King13a(p.3.2.4/5)</link>].</simpara></footnote></simpara>
-<section xml:id="intersection-type-syntax">
-<title>Syntax</title>
-<simpara>For convenience, we repeat the definition of intersection type expression and of type variables in which intersection types can be defined as in Java:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">InterSectionTypeExpression: 'intersection' '{' typeRefs+=TypeRefWithoutModifiers (',' typeRefs+=TypeRefWithoutModifiers)* '}';
-
-TypeVariable: name=IDENTIFIER ('extends' declaredUpperBounds+=ParameterizedTypeRefNominal ('&' declaredUpperBounds+=ParameterizedTypeRefNominal)*)?</programlisting>
-</section>
-<section xml:id="intersection-type-semantics">
-<title>Semantics</title>
-<simpara>An intersection type may contain several interfaces but only one class.
-It virtually declares a subclass of this one class and implements all interfaces declared in the intersection type.
-If no class is declared in the intersection type, the intersection type virtually declares a subclass of an N4Object instead.
-This virtual subclass also explains why only one single class may be contained in the intersection.</simpara>
-<requirement xml:id="IDE-27">
-<title>Intersection Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-27" xreflabel="[Req-IDE-27]"/>
-<emphasis role="strong">Requirement: IDE-27:</emphasis>
-<link linkend="Req-IDE-27">Intersection Type</link> (ver. 1)</simpara>
- <simpara>
-
-For a given intersection type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi></math>, the following conditions must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The intersection must contain at least one type:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>≠</mo><mi>∅</mi></math>
-</listitem>
-<listitem>
-<simpara>Only one class must be contained in the intersection type:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close=")" open="("><mrow><mo>∃</mo><mi>C</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>C</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle></mrow></mfenced><mo>→</mo><mo>∄</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>∖</mo><mfenced close="}" open="{"><mi>C</mi></mfenced><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle></math>
-<simpara>For the time being, only a warning is produced when more than one class is contained in the intersection type .</simpara>
-</listitem>
-<listitem>
-<simpara>Non-optional elements:</simpara>
-</listitem>
-</orderedlist>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>→</mo><mo>¬</mo><mi>T</mi><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></math>
-</requirement>
-<requirement xml:id="IDE-175">
-<title>Intersection Type Subtyping Rules</title>
-<simpara>
-<anchor xml:id="Req-IDE-175" xreflabel="[Req-IDE-175]"/>
-<emphasis role="strong">Requirement: IDE-175:</emphasis>
-<link linkend="Req-IDE-175">Intersection Type Subtyping Rules</link> (ver. 1)</simpara>
- <simpara>
-
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi></math> be an intersection type.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>An intersection type is a subtype of another type, if at least one of
-its contained types is a subtype of that type: <footnote><simpara>This rule is a generalization of the subtyping rules given in [<link linkend="Laurent12a">Laurent12a</link>] Table 2, <math xmlns="http://www.w3.org/1998/Math/MathML"><msubsup><mo>∩</mo><mi>l</mi><mn>1</mn></msubsup></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msubsup><mo>∩</mo><mi>l</mi><mn>2</mn></msubsup></math></simpara></footnote></simpara>
-</listitem>
-</itemizedlist>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mo>∃</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></mrow><mrow><mi>I</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></mrow></mfrac></math>
-<itemizedlist>
-<listitem>
-<simpara>A type is a subtype of an intersection type, if it is a subtype of all
-types contained in the intersection type: <footnote><simpara>This rule is a generalization of the subtyping rules given in [<link linkend="Laurent12a">Laurent12a</link>] Table 2, <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mo>∩</mo><mi>r</mi></msub></math></simpara></footnote></simpara>
-</listitem>
-</itemizedlist>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mo>∀</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>S</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi></mrow><mrow><mi>S</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>I</mi></mrow></mfrac></math>
-<itemizedlist>
-<listitem>
-<simpara>Non-optional elements:
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>→</mo><mo>¬</mo><mi>T</mi><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-28">
-<title>Implicit simplification of intersection types</title>
-<simpara>
-<anchor xml:id="Req-IDE-28" xreflabel="[Req-IDE-28]"/>
-<emphasis role="strong">Requirement: IDE-28:</emphasis>
-<link linkend="Req-IDE-28">Implicit simplification of intersection types</link> (ver. 1)</simpara>
- <simpara>
-
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi></math> be an intersection type.
-The following simplification rules are always automatically applied to intersection types.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The structural typing strategy is propagated to the types of the intersection:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>~</mi><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced></mrow><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>~</mi><msub><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mn>1</mn></msub><mo>,</mo><mi>…</mi><mo>,</mo><mi>~</mi><msub><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mi>n</mi></msub></mrow></mfenced></mrow></mfrac></math>
-</listitem>
-</itemizedlist>
-<simpara>These subtyping rules are similar to Ceylon. <footnote><simpara>In Ceylon, for a given union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>=</mo><msub><mi>T</mi><mn>1</mn></msub><mo>|</mo><msub><mi>T</mi><mn>2</mn></msub></math> and intersection type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mo>=</mo><msub><mi>T</mi><mn>1</mn></msub><mi>&</mi><msub><mi>T</mi><mn>2</mn></msub></math> (with ’|’ is union and ’&’ is intersection), <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mn>1</mn></msub><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>U</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mn>2</mn></msub><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>U</mi></math> is true, and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mn>1</mn></msub><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>I</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mn>2</mn></msub><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>I</mi></math> is true. We should define that as well (if it is not already defined). Cf [<link linkend="King13a">King13a(p.3.2.4/5)</link>]</simpara></footnote></simpara>
-<simpara>During validation, intersection types containing union or other intersection types may be inferred.
-In this case, the composed types are flattened.
-The aforementioned constraints must hold.
-We also implicitly use this representation in this specification.</simpara>
-<example>
-<title>Subtyping with intersection type</title>
-<simpara>Let A, B, and C be defined as in the chapter beginning (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo><</mo><mi>:</mi><mi>B</mi><mo><</mo><mi>:</mi><mi>A</mi></math>)</simpara>
-<simpara>The following subtyping relations with intersection types are to be
-evaluated as follows: <footnote><simpara>See Example <xref linkend="ex:class-hierarchy"/> for class definitions.</simpara></footnote></simpara>
-<programlisting language="xtext" linenumbering="unnumbered">A <: intersection{A} -> true
-A <: intersection{A,A} -> true
-intersection{A,X} <: A -> true
-intersection{X,A} <: A -> true
-A <: intersection{A,X} -> false
-intersection{A,X} <: intersection{X,A} -> true
-H12 <: intersection{I1,I2} -> true
-intersection{I1,I2} <: H12 -> false
-H1 <: intersection{I1,I2} -> false
-H23 <: intersection{I1,I2} -> false
-B <: intersection{A} -> true
-intersection{I1,I2} <: I -> true
-H12 <: intersection{I,I2} -> true
-A <: intersection{A,Any} -> true
-intersection{A,Any} <: A -> true</programlisting>
-</example>
-</requirement>
-<simpara>The join of intersection types is defined as the join of the elements.
-That is:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>∨</mo><mi>S</mi><mo>∨</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>∨</mo><msub><mi>T</mi><mi>n</mi></msub><mo>∨</mo><mi>S</mi></mrow><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced><mo>∨</mo><mi>S</mi></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>∨</mo><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mn>1</mn></msub><mo>∨</mo><msub><mi>S</mi><mi>m</mi></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>∨</mo><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>∨</mo><msub><mi>S</mi><mi>m</mi></msub></mrow><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced><mo>∨</mo><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mi>m</mi></msub></mrow></mfenced></mrow></mfrac></math></simpara>
-
-<simpara>The meet of intersection types is defined over their elements.
-That is:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>∧</mo><mi>S</mi><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>∧</mo><mi>S</mi></mrow></mfenced></mrow><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced><mo>∧</mo><mi>S</mi></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>∧</mo><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mn>1</mn></msub><mo>∧</mo><msub><mi>S</mi><mi>m</mi></msub><mo>,</mo><mspace width="1em"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><mspace width="1em"/><msub><mi>T</mi><mi>n</mi></msub><mo>∧</mo><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>∧</mo><msub><mi>S</mi><mi>m</mi></msub></mrow></mfenced></mrow><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced><mo>∧</mo><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mi>m</mi></msub></mrow></mfenced></mrow></mfrac></math></simpara>
-
-<simpara>The upper and lower bound of an intersection type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi></math> is a union type <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>I</mi><mi>'</mi></msup></math> containing the upper and lower bound of the elements of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi></math>:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced></mrow></mfenced><mi>:</mi><mo>=</mo><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>T</mi><mn>1</mn></msub></mfenced><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>T</mi><mn>1</mn></msub></mfenced></mrow></mfenced></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mrow><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></mrow></mfenced></mrow></mfenced><mi>:</mi><mo>=</mo><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>T</mi><mn>1</mn></msub></mfenced><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>T</mi><mn>1</mn></msub></mfenced></mrow></mfenced></math></simpara>
-
-</section>
-<section xml:id="_warnings-2">
-<title>Warnings</title>
-<simpara>Using <literal>any</literal> types in intersection types is obsolete since they do not change the resulting intersection type.
-E.g. the intersection type of A, B and <literal>any</literal> is equivialent to the intersection type of A and B.
-However, using the <literal>any</literal> type is no error because it can be seen as a neutral argument to the intersection.
-Nevertheless the use of the <literal>any</literal> type produces a warning, since its use can indicate a misunderstanding of the intersection type concept and since it always can be omitted.</simpara>
-<requirement xml:id="IDE-32">
-<title>Any type in intersection types</title>
-<simpara>
-<anchor xml:id="Req-IDE-32" xreflabel="[Req-IDE-32]"/>
-<emphasis role="strong">Requirement: IDE-32:</emphasis>
-<link linkend="Req-IDE-32">Any type in intersection types</link> (ver. 1)</simpara>
- <simpara>
-
-No intersection type shall contain an type:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∄</mo><mi>a</mi><mi>n</mi><mi>y</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi></math></simpara>
-</requirement>
-<simpara>The use of the <literal>any</literal> type in an intersection type is similar to the following case.
-When two types are used, one of them a supertype of the other, then this supertype is obsolete.
-Hence, a warning will be produced to indicate unecessary code.
-The warning is only produced when both of the types are either classes or interfaces, since e.g. structural types are supertypes of any classes or interfaces.</simpara>
-<requirement xml:id="IDE-33">
-<title>Redundant supertypes in intersection types</title>
-<simpara>
-<anchor xml:id="Req-IDE-33" xreflabel="[Req-IDE-33]"/>
-<emphasis role="strong">Requirement: IDE-33:</emphasis>
-<link linkend="Req-IDE-33">Redundant supertypes in intersection types</link> (ver. 1)</simpara>
- <simpara>
-
-Intersection types shall not contain class or interface types which are a supertype of another class or interface type that also is contained in the intersection type.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∄</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mo>∃</mo><mi>T</mi><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mtext>
-</mtext><mrow><mo>(</mo><mrow><mi>T</mi><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi><mo>∧</mo><mi>i</mi><mi>s</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mi>O</mi><mi>r</mi><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∧</mo><mi>i</mi><mi>s</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mi>O</mi><mi>r</mi><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mfenced close=")" open="("><mrow><mi>T</mi><mi>T</mi></mrow></mfenced><mo>)</mo></mrow></mrow></math>
-</requirement>
-</section>
-</section>
-<section xml:id="_composed-types-in-wildcards">
-<title>Composed Types in Wildcards</title>
-<simpara>Composed types may appear as the bound of a wildcard.
-The following constraints apply: <footnote><simpara>see "Covariance and contravariance with unions and intersections" at <link xl:href="http://ceylon-lang.org/documentation/1.1/tour/generics/">http://ceylon-lang.org/documentation/1.1/tour/generics/</link></simpara></footnote></simpara>
-<requirement xml:id="IDE-34">
-<title>Composed Types as Bound of a Wildcard</title>
-<simpara>
-<anchor xml:id="Req-IDE-34" xreflabel="[Req-IDE-34]"/>
-<emphasis role="strong">Requirement: IDE-34:</emphasis>
-<link linkend="Req-IDE-34">Composed Types as Bound of a Wildcard</link> (ver. 1)</simpara>
- <simpara>
-
-A composed type may appear as the upper or lower bound of a wildcard.
-In the covariant case, the following subtype relations apply:</simpara>
-<programlisting language="ebnf" linenumbering="unnumbered">union{ G<? extends A>, G<? extends B> } \subtype G<? extends union{A,B}>
-G<? extends intersection{A,B}> \subtype intersection{ G<? extends A>, G<? extends B> }</programlisting>
-<simpara>In the contra variant case, the following subtype relations apply:</simpara>
-<programlisting language="ebnf" linenumbering="unnumbered">union{ G<? super A>, G<? super B> } \subtype G<? super intersection{A,B}>
-G<? super union{A,B}> \subtype intersection{ G<? super A>, G<? super B> }</programlisting>
-</requirement>
-</section>
-<section xml:id="_property-access-for-composed-types">
-<title>Property Access for Composed Types</title>
-<simpara>It is possible to directly access properties of union and intersection types.
-The following sections define which properties are accessible.</simpara>
-<section xml:id="_properties-of-union-type">
-<title>Properties of Union Type</title>
-<simpara>As an (oversimplified) rule of thumb, the properties of a union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>=</mo><msub><mi>T</mi><mn>1</mn></msub><mo>|</mo><msub><mi>T</mi><mn>2</mn></msub></math> are simply the intersection of the properties <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>i</mi><mi>e</mi><mi>s</mi><mo>=</mo><msub><mi>T</mi><mn>1</mn></msub><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>i</mi><mi>e</mi><mi>s</mi><mo>∩</mo><msub><mi>T</mi><mn>2</mn></msub><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>i</mi><mi>e</mi><mi>s</mi></math>.
-In other words, a property 'p' in the union type is the least common denominator of all 'p' in T_{1} and T_{2}.
-It is not quite that simple, however, as the question of "equality" with regards to properties has to be answered.</simpara>
-<simpara><?asciidoc-hr?></simpara>
-<simpara>For a given union type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>U</mi><mo>=</mo><msub><mi>T</mi><mn>1</mn></msub><mo>|</mo><msub><mi>T</mi><mn>2</mn></msub></math>, the following constraints for its members must hold:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi> </mi><mi>a</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>a</mi><mi>t</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>b</mi><mi>u</mi><mi>t</mi><mi>e</mi><mi>s</mi><mi>:</mi></math></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd/><mtd><mo>∀</mo><mi> </mi><mi>k</mi><mo>∈</mo><mfenced close="}" open="{"><mn>1</mn><mn>2</mn></mfenced><mi>:</mi><mo>∃</mo><mi> </mi><msub><mi>a</mi><mi>k</mi></msub><mo>∈</mo><msub><mi>T</mi><mi>k</mi></msub><mo>.</mo><mi>a</mi><mi>t</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>b</mi><mi>u</mi><mi>t</mi><mi>e</mi><mi>s</mi><mi>:</mi><msub><mi>a</mi><mi>k</mi></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>></mo><mi>p</mi><mi>r</mi><mi>i</mi><mi>v</mi><mi>a</mi><mi>t</mi><mi>e</mi></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>a</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mi>m</mi><mi>i</mi><mi>n</mi><mfenced close=")" open="("><mrow><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mrow><mrow><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mrow></mfenced></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>a</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>a</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd></mtr></mtable></math>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi> </mi><mi>m</mi><mo>∈</mo><mi>U</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mi>:</mi></math></simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∃</mo><mi> </mi><msub><mi>m</mi><mn>1</mn></msub><mo>∈</mo><msub><mi>T</mi><mn>1</mn></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mo>,</mo><msub><mi>m</mi><mn>2</mn></msub><mo>∈</mo><msub><mi>T</mi><mn>2</mn></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mo>,</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><mstyle mathvariant="bold"><mi>w</mi><mi>i</mi><mi>t</mi><mi>h</mi></mstyle><mi>p</mi><mo>=</mo><mi>m</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>∧</mo><msup><mi>p</mi><mi>'</mi></msup><mo>=</mo><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>∧</mo><mi>p</mi><mi>"</mi><mo>=</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>,</mo><mstyle mathvariant="bold"><mi>W</mi><mi>L</mi><mi>O</mi><mi>G</mi></mstyle><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>≤</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mi>:</mi></math><?asciidoc-br?></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd/><mtd><mspace width="1.2em"/><mo>∀</mo><mi>k</mi><mo>∈</mo><mfenced close="}" open="{"><mn>1</mn><mn>2</mn></mfenced><mi>:</mi><msub><mi>m</mi><mi>k</mi></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>></mo><mi>p</mi><mi>r</mi><mi>i</mi><mi>v</mi><mi>a</mi><mi>t</mi><mi>e</mi></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mi>m</mi><mi>i</mi><mi>n</mi><mfenced close=")" open="("><mrow><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mrow><mrow><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mrow></mfenced></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>m</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>|</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mo>∀</mo><mi> </mi><mi>i</mi><mo><</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mi>:</mi><msub><mi>p</mi><mi>i</mi></msub><mi> </mi><mstyle mathvariant="bold"><mi>e</mi><mi>x</mi><mi>i</mi><mi>s</mi><mi>t</mi><mi>s</mi></mstyle><mspace width="1.0mm"/><mstyle mathvariant="bold"><mi>w</mi><mi>i</mi><mi>t</mi><mi>h</mi></mstyle></mtd></mtr><mtr><mtd/><mtd><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd><mtd><mi>i</mi><mo>≥</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>∨</mo><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd></mtr><mtr><mtd><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>+</mo><mstyle mathvariant="bold"><mi>"</mi><mi>_</mi><mi>"</mi></mstyle><mo>+</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>&</mi><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><mi>i</mi><mo><</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo></mtd></mtr><mtr><mtd><msub><msup><mi>p</mi><mi>'</mi></msup><mrow><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>-</mo><mn>1</mn></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>&</mi><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><mi>i</mi><mo>≥</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>∧</mo><msub><msup><mi>p</mi><mi>'</mi></msup><mrow><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>-</mo><mn>1</mn></mrow></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mtd></mtr><mtr><mtd><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><mfenced close=")" open="("><mrow><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>∧</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></mrow></mfenced></mtd><mtd><mi>i</mi><mo><</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo></mtd></mtr><mtr><mtd><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>∧</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mtd><mtd><mi>i</mi><mo><</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>∧</mo><mi>i</mi><mo>=</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mo>-</mo><mn>1</mn></mtd></mtr><mtr><mtd><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mtd><mtd><mi>i</mi><mo>≥</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>∧</mo><mi>i</mi><mo>=</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mo>-</mo><mn>1</mn></mtd></mtr><mtr><mtd><mi>f</mi><mi>a</mi><mi>l</mi><mi>s</mi><mi>e</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr></mtable></math>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∧</mo><mrow><mo>(</mo><mi>l</mi><mo>=</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>=</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mo>∧</mo><mo>¬</mo><mfenced close=")" open="("><mrow><msub><msup><mi>p</mi><mi>'</mi></msup><mi>l</mi></msub><mo>-</mo><mn>1</mn><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>∧</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mrow><mi>l</mi><mo>-</mo><mn>1</mn></mrow></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></mrow></mfenced><mo>∧</mo><mo>∃</mo><mi>v</mi><mo>∈</mo><mfenced close="}" open="{"><mrow><mi>p</mi><msub><mi>'</mi><mi>l</mi></msub><mo>-</mo><mn>1</mn></mrow><mrow><mi>p</mi><msub><mi>"</mi><mi>l</mi></msub><mo>-</mo><mn>1</mn></mrow></mfenced><mi>v</mi><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>:</mi><msub><mi>p</mi><mi>l</mi></msub><mi> </mi><mstyle mathvariant="bold"><mi>e</mi><mi>x</mi><mi>i</mi><mi>s</mi><mi>t</mi><mi>s</mi></mstyle><mspace width="1.0mm"/><mstyle mathvariant="bold"><mi>w</mi><mi>i</mi><mi>t</mi><mi>h</mi></mstyle></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msub><mi>p</mi><mi>l</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>v</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><mi>v</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>=</mo><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>=</mo><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi></math></simpara>
-<simpara><?asciidoc-hr?></simpara>
-<simpara>The following table shows how non-method members of union types are merged.
-The resulting member type depends on whether the member is being accessed during a read (R) or write (W) operation.
-The type of a field, of a getter or of the parameter of a setter is indicated in brackets.</simpara>
-<table frame="all" rowsep="1" colsep="1">
-<title>Merged Members of Unions</title>
-<tgroup cols="5">
-<colspec colname="col_1" colwidth="20*"/>
-<colspec colname="col_2" colwidth="20*"/>
-<colspec colname="col_3" colwidth="20*"/>
-<colspec colname="col_4" colwidth="20*"/>
-<colspec colname="col_5" colwidth="20*"/>
-<thead>
-<row>
-<entry align="center" valign="top">Members</entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3">S=T</entry>
-<entry align="center" valign="top" namest="col_3" nameend="col_4">S≠T</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">R</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">W</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">R</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">W</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">field:S | field:T</emphasis></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3"><simpara>field:S</simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S|T</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S&T</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">getter:S | getter:T</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S|T</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">setter:S | setter:T</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S&T</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">field:S | getter:T</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S|T</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">field:S | setter:T</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S&T</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">getter:S | setter:T</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<section xml:id="_remarks-on-union-type-s-members">
-<title>Remarks on union type’s members:</title>
-<itemizedlist>
-<listitem>
-<simpara>Fields of the same type are merged to a composed field with the same type.
-Fields of different types are merged to a getter and setter.</simpara>
-</listitem>
-<listitem>
-<simpara>The return type of a composed getter is the <emphasis>union</emphasis> type of the return types of the merged getters.</simpara>
-</listitem>
-<listitem>
-<simpara>The type of a composed setter is the <emphasis>intersection</emphasis> type of the types of the merged setters.</simpara>
-</listitem>
-<listitem>
-<simpara>Fields can be combined with getters and/or setters:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>fields combined with getters allow read-access.</simpara>
-</listitem>
-<listitem>
-<simpara>non-const fields combined with setters allow write-access.</simpara>
-</listitem>
-<listitem>
-<simpara>non-const fields combined with getters <emphasis>and</emphasis> setters, i.e. each type has either a non-const field or both a getter and a setter of the given name, allow both read- and write-access.</simpara>
-<simpara>Again, types need not be identical; for read-access the <emphasis>union</emphasis> of the fields’ types and the getters’ return types is formed, for write-access the <emphasis>intersection</emphasis> of the fields’ types and the setters’ types is formed.
-In the third case above, types are combined independently for read- and write-access if the getters and setters have different types.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>The name of a method’s parameter is only used for error or warning messages and cannot be referenced otherwise.</simpara>
-</listitem>
-<listitem>
-<simpara>The return type of a composed method is the <emphasis>union</emphasis> type of the return types of the merged methods.</simpara>
-</listitem>
-<listitem>
-<simpara>A composed method parameter’s type is the <emphasis>intersection</emphasis> type of the merged parameters types.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-<section xml:id="_properties-of-intersection-type">
-<title>Properties of Intersection Type</title>
-<simpara>As an (oversimplified) rule of thumb, the properties of an intersection type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mo>=</mo><msub><mi>T</mi><mn>1</mn></msub><mi>&</mi><msub><mi>T</mi><mn>2</mn></msub></math> are the union of properties <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>i</mi><mi>e</mi><mi>s</mi><mo>=</mo><msub><mi>T</mi><mn>1</mn></msub><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>i</mi><mi>e</mi><mi>s</mi><mo>∪</mo><msub><mi>T</mi><mn>2</mn></msub><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>i</mi><mi>e</mi><mi>s</mi></math>.
-In other words, a property 'p' in the union type is the greates common denominator of all 'p' in T_{1} and T_{2}.
-It is not quite that simple, however, as the question of "equality” with regards to properties has to be answered.</simpara>
-<requirement xml:id="IDE-36">
-<title>Members of an Intersection Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-36" xreflabel="[Req-IDE-36]"/>
-<emphasis role="strong">Requirement: IDE-36:</emphasis>
-<link linkend="Req-IDE-36">Members of an Intersection Type</link> (ver. 1)</simpara>
- <simpara>
-
-For a given intersection type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mo>=</mo><msub><mi>T</mi><mn>1</mn></msub><mi>&</mi><msub><mi>T</mi><mn>2</mn></msub></math>, the following constraints for its members must hold:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>a</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>a</mi><mi>t</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>b</mi><mi>u</mi><mi>t</mi><mi>e</mi><mi>s</mi><mi>:</mi></math></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd/><mtd><mrow><mo>(</mo><mrow><mo>∃</mo><msub><mi>a</mi><mn>1</mn></msub><mo>∈</mo><msub><mi>T</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>t</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>b</mi><mi>u</mi><mi>t</mi><mi>e</mi><mi>s</mi><mo>,</mo><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>></mo><mi>p</mi><mi>r</mi><mi>i</mi><mi>v</mi><mi>a</mi><mi>t</mi><mi>e</mi><mo>)</mo></mrow><mo>∨</mo><mrow><mo>(</mo><mrow><mo>∃</mo><msub><mi>a</mi><mn>2</mn></msub><mo>∈</mo><msub><mi>T</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>t</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>b</mi><mi>u</mi><mi>t</mi><mi>e</mi><mi>s</mi><mo>,</mo><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>></mo><mi>p</mi><mi>r</mi><mi>i</mi><mi>v</mi><mi>a</mi><mi>t</mi><mi>e</mi><mo>)</mo></mrow></mrow></mrow></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>a</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd><mtd><msub><mi>a</mi><mn>1</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mfenced close=")" open="("><mrow><msub><mi>a</mi><mn>2</mn></msub><mo>=</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∨</mo><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mrow></mfenced></mtd></mtr><mtr><mtd><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>a</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mtd><mtd><msub><mi>a</mi><mn>1</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mfenced close=")" open="("><mrow><msub><mi>a</mi><mn>2</mn></msub><mo>=</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∨</mo><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>≤</mo><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mrow></mfenced></mtd></mtr><mtr><mtd><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>a</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>&</mi><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><msub><mi>a</mi><mn>1</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><msub><mi>a</mi><mn>2</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></mtd></mtr><mtr><mtd><msub><mi>a</mi><mn>1</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><msub><mi>a</mi><mn>1</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></mtd></mtr><mtr><mtd><msub><mi>a</mi><mn>2</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle><mfenced close=")" open="("><mrow><msub><mi>a</mi><mn>2</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></mrow></mfenced></mtd></mtr></mtable></mfenced></mtd></mtr></mtable></math>
-<simpara><?asciidoc-pagebreak?></simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi></math>:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>(</mo><mrow><mo>∃</mo><msub><mi>m</mi><mn>1</mn></msub><mo>∈</mo><msub><mi>T</mi><mn>1</mn></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mo>,</mo><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>></mo><mi>p</mi><mi>r</mi><mi>i</mi><mi>v</mi><mi>a</mi><mi>t</mi><mi>e</mi><mo>)</mo></mrow><mo>∨</mo><mrow><mo>(</mo><mrow><mo>∃</mo><msub><mi>m</mi><mn>2</mn></msub><mo>∈</mo><msub><mi>T</mi><mn>1</mn></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mo>,</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>></mo><mi>p</mi><mi>r</mi><mi>i</mi><mi>v</mi><mi>a</mi><mi>t</mi><mi>e</mi><mo>)</mo></mrow><mi>:</mi></mrow></mrow></math></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd/><mtd><mspace width="2.0em"/><mstyle mathvariant="bold"><mi>w</mi><mi>i</mi><mi>t</mi><mi>h</mi></mstyle><mi>p</mi><mo>=</mo><mi>m</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi></mtd></mtr><mtr><mtd/><mtd><mspace width="3.0em"/><mo>∧</mo><mstyle mathvariant="bold"><mi>i</mi><mi>f</mi></mstyle><mi> </mi><msub><mi>m</mi><mn>1</mn></msub><mi> </mi><mstyle mathvariant="bold"><mi>e</mi><mi>x</mi><mi>i</mi><mi>s</mi><mi>t</mi><mi>s</mi></mstyle><mi> </mi><msup><mi>p</mi><mi>'</mi></msup><mo>=</mo><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mi> </mi><mstyle mathvariant="bold"><mfenced close=")" open="("><mrow><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi><msup><mi>p</mi><mi>'</mi></msup><mo>=</mo><mi>∅</mi></mrow></mfenced></mstyle><mo>,</mo></mtd></mtr><mtr><mtd/><mtd><mspace width="3.0em"/><mo>∧</mo><mstyle mathvariant="bold"><mi>i</mi><mi>f</mi></mstyle><mi> </mi><msub><mi>m</mi><mn>2</mn></msub><mi> </mi><mstyle mathvariant="bold"><mi>e</mi><mi>x</mi><mi>i</mi><mi>s</mi><mi>t</mi><mi>s</mi></mstyle><mi> </mi><mi>p</mi><mi>"</mi><mo>=</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mi> </mi><mstyle mathvariant="bold"><mfenced close=")" open="("><mrow><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi><mi>p</mi><mi>"</mi><mo>=</mo><mi>∅</mi></mrow></mfenced></mstyle><mo>,</mo><mstyle mathvariant="bold"><mstyle mathvariant="bold"><mi>W</mi><mi>L</mi><mi>O</mi><mi>G</mi></mstyle></mstyle><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>≤</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mi>:</mi></mtd></mtr><mtr><mtd/><mtd><mspace width="1.0em"/><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd><mtd><msub><mi>m</mi><mn>1</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mfenced close=")" open="("><mrow><msub><mi>m</mi><mn>2</mn></msub><mo>=</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∨</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mrow></mfenced></mtd></mtr><mtr><mtd><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mtd><mtd><msub><mi>m</mi><mn>1</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mfenced close=")" open="("><mrow><msub><mi>m</mi><mn>2</mn></msub><mo>=</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∨</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>≤</mo><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mrow></mfenced></mtd></mtr><mtr><mtd><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mi>m</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>&</mi><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><msub><mi>m</mi><mn>1</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><msub><mi>m</mi><mn>2</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></mtd></mtr><mtr><mtd><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><msub><mi>m</mi><mn>1</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></mtd></mtr><mtr><mtd><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle><mfenced close=")" open="("><mrow><msub><mi>m</mi><mn>2</mn></msub><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></mrow></mfenced></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mo>∧</mo><mo>∀</mo><mi> </mi><mi>i</mi><mo><</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mi>:</mi><msub><mi>p</mi><mi>i</mi></msub><mi> </mi><mstyle mathvariant="bold"><mi>e</mi><mi>x</mi><mi>i</mi><mi>s</mi><mi>t</mi><mi>s</mi><mi>w</mi><mi>i</mi><mi>t</mi><mi>h</mi></mstyle></mtd></mtr><mtr><mtd/><mtd><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd><mtd><mi>i</mi><mo>≥</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>∨</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd></mtr><mtr><mtd><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>+</mo><mstyle mathvariant="bold"><mi>"</mi><mi>_</mi><mi>"</mi></mstyle><mo>+</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>|</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><mi>i</mi><mo><</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo></mtd></mtr><mtr><mtd><msub><msup><mi>p</mi><mi>'</mi></msup><mrow><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>-</mo><mn>1</mn></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>|</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><mi>i</mi><mo>≥</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>∧</mo><msub><msup><mi>p</mi><mi>'</mi></msup><mrow><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>-</mo><mn>1</mn></mrow></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mtd></mtr><mtr><mtd><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr><mtr><mtd/><mtd><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>=</mo><mfenced close=")" open="("><mrow><mo>∃</mo><mi>k</mi><mo>≤</mo><mi>m</mi><mi>i</mi><mi>n</mi><mfenced close=")" open="("><mrow><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>-</mo><mn>1</mn></mrow><mi>i</mi></mfenced><mi>:</mi><mi>p</mi><msub><mi>'</mi><mi>k</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></mrow></mfenced><mo>∨</mo><mfenced close=")" open="("><mrow><mo>∃</mo><mi>k</mi><mo>≤</mo><mi>i</mi><mi>:</mi><mi>p</mi><msub><mi>"</mi><mi>k</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></mrow></mfenced></mtd></mtr><mtr><mtd/><mtd><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>∨</mo><mfenced close=")" open="("><mrow><msub><msup><mi>p</mi><mi>'</mi></msup><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>∨</mo><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mrow></mfenced></mtd><mtd><mi>i</mi><mo><</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>∧</mo><mi>i</mi><mo>=</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mo>-</mo><mn>1</mn></mtd></mtr><mtr><mtd><msub><mrow><mi>p</mi><mi>"</mi></mrow><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mtd><mtd><mi>i</mi><mo>≥</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>∧</mo><mi>i</mi><mo>=</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mo>-</mo><mn>1</mn></mtd></mtr><mtr><mtd><mi>f</mi><mi>a</mi><mi>l</mi><mi>s</mi><mi>e</mi></mtd><mtd><mstyle mathvariant="bold"><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr></mtable></math>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∧</mo><mrow><mo>(</mo><mi>l</mi><mo>=</mo><mo>|</mo><msup><mi>p</mi><mi>'</mi></msup><mo>|</mo><mo>=</mo><mo>|</mo><mi>p</mi><mi>"</mi><mo>|</mo><mo>∧</mo><mi>l</mi><mo>></mo><mn>0</mn><mo>∧</mo><mo>¬</mo><mfenced close=")" open="("><mrow><msub><mi>p</mi><mrow><mi>l</mi><mo>-</mo><mn>1</mn></mrow></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></mrow></mfenced><mo>∧</mo><mo>∃</mo><mi>v</mi><mo>∈</mo><mfenced close="}" open="{"><mrow><mi>p</mi><msub><mi>'</mi><mrow><mi>l</mi><mo>-</mo><mn>1</mn></mrow></msub></mrow><mrow><mi>p</mi><msub><mi>"</mi><mrow><mi>l</mi><mo>-</mo><mn>1</mn></mrow></msub></mrow></mfenced><mi>v</mi><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>:</mi><msub><mi>p</mi><mi>l</mi></msub><mi> </mi><mstyle mathvariant="bold"><mi>e</mi><mi>x</mi><mi>i</mi><mi>s</mi><mi>t</mi><mi>s</mi></mstyle><mspace width="1.0mm"/><mstyle mathvariant="bold"><mi>w</mi><mi>i</mi><mi>t</mi><mi>h</mi></mstyle></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msub><mi>p</mi><mi>l</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>v</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>=</mo><mi>v</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>=</mo><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msub><mi>p</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>=</mo><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi></math></simpara>
-</requirement>
-<simpara>The following table shows how non-method members of intersection types are merged.
-The resulting member type depends on whether the member is being accessed during a read (R) or write (W) operation.
-The type of a field, of a getter or of the parameter of a setter is indicated in brackets.</simpara>
-<table frame="all" rowsep="1" colsep="1">
-<title>Merged Members of Intersections</title>
-<tgroup cols="5">
-<colspec colname="col_1" colwidth="20*"/>
-<colspec colname="col_2" colwidth="20*"/>
-<colspec colname="col_3" colwidth="20*"/>
-<colspec colname="col_4" colwidth="20*"/>
-<colspec colname="col_5" colwidth="20*"/>
-<thead>
-<row>
-<entry align="center" valign="top">Members</entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3">S=T</entry>
-<entry align="center" valign="top" namest="col_3" nameend="col_4">S≠T</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">R</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">W</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">R</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">W</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">field:S & field:T</emphasis></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3"><simpara>field:S</simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S&T</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S|T</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">getter:S & getter:T</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S&T</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">setter:S & setter:T</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S</simpara></entry>
-<entry align="center" valign="top"><simpara>-</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S|T</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">field:S & getter:T</emphasis></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3"><simpara>field:S</simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S&T</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">field:S & setter:T</emphasis></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3"><simpara>field:S</simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:S|T</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">getter:S & setter:T</emphasis></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3"><simpara>field:S</simpara></entry>
-<entry align="center" valign="top"><simpara>getter:S</simpara></entry>
-<entry align="center" valign="top"><simpara>setter:T</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<section xml:id="_remarks-on-intersection-type-s-methods">
-<title>Remarks on intersection type’s methods:</title>
-<itemizedlist>
-<listitem>
-<simpara>The name of a method’s parameter is only used for error or warning messages and cannot be referenced otherwise.</simpara>
-</listitem>
-<listitem>
-<simpara>The return type of a method is the <emphasis>intersection</emphasis> type of the return types of the merged methods.</simpara>
-</listitem>
-<listitem>
-<simpara>A method parameter’s type is the <emphasis>union</emphasis> type of the merged parameters types.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-</section>
-</section>
-<section xml:id="_constructor-and-classifier-type" role="language-n4js">
-<title>Constructor and Classifier Type</title>
-<simpara>A class definition as described in <xref linkend="_classes"/> declares types.
-Often, it is necessary to access these types directly, for example to access staticmembers or for dynamic construction of instances.
-These two use cases are actually slightly different and N4JS provides two different types, one for each use case: constructor and classifier type.<footnote><simpara>The classifier type is, in fact, the <literal>type type</literal> or <literal>metatype</literal> of a type. We use the term classifier type in the specification to avoid the bogus <literal>type type</literal> terminology.</simpara></footnote>
-The constructor is basically the classifier type with the additional possibility to call it via <literal>new</literal> in order to create new instances of the declared type.</simpara>
-<simpara>Both <literal>meta</literal> types are different from Java’s type <literal>Class<T></literal>, as the latter has a defined set of members, while the N4JS metatypes will have members according to a class definition.
-The concept of constructors as metatypes is similar to ECMAScript 2015 [<link linkend="ECMA15a">ECMA15a(p.14.5)</link>].</simpara>
-<section xml:id="_syntax-3">
-<title>Syntax</title>
-<programlisting language="n4js" linenumbering="unnumbered">ConstructorTypeRef returns ConstructorTypeRef: 'constructor' '{' typeArg = [TypeArgument] '}';
-
-ClassifierTypeRef returns ClassifierTypeRef: 'type' '{' typeArg = [TypeRef] '}';</programlisting>
-</section>
-<section xml:id="_semantics-2">
-<title>Semantics</title>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Static members of a type <emphasis>T</emphasis> are actually members of the classifier type <literal>type{T}</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The keyword <literal>this</literal> in a static method of a type <emphasis>T</emphasis> actually binds to the classifier type <literal>type{T}</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The constructor type <literal>constructor</literal><emphasis>{T}</emphasis> is a subtype of the classifier type <literal>type{T}</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><mi>T</mi><mi>:</mi><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mfenced close="}" open="{"><mi>T</mi></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mfenced close="}" open="{"><mi>T</mi></mfenced></math>
-</listitem>
-<listitem>
-<simpara>If a class <emphasis>B</emphasis> is a subtype (subclass) of a class <emphasis>A</emphasis>, then the classifier type <literal>type{B}</literal> also is a subtype of <literal>type{A}</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi></mrow><mrow><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mfenced close="}" open="{"><mi>B</mi></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mfenced close="}" open="{"><mi>A</mi></mfenced></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>If a class <emphasis>B</emphasis> is a subtype (subclass) of a class <emphasis>A</emphasis>, and if the constructor function of <emphasis>B</emphasis> is a subtype of the constructor function of <emphasis>A</emphasis>, then the
-classifier type <literal>constructor{B}</literal> also is a subtype of <literal>constructor{A}</literal> :</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>B</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi><mspace width="3.0mm"/><mi>B</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>A</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></mrow><mrow><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mfenced close="}" open="{"><mi>B</mi></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mfenced close="}" open="{"><mi>A</mi></mfenced></mrow></mfrac></math>
-<simpara>The subtype relation of the constructor function is defined in <xref linkend="_function-type"/>.
-In the case of the default <literal>N4Object</literal> constructor, the type of the object literal argument depends on required attributes.</simpara>
-<simpara>This subtype relation for the constructor type is enforced if the constructor of the super class is marked as <literal>final</literal>, see <xref linkend="_constructor-and-classifier-type"/> for details.</simpara>
-</listitem>
-<listitem>
-<simpara>The type of a classifier declaration or classifier expression is the constructor of that class:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>μ</mi><mfenced close=")" open="("><mi>C</mi></mfenced><mo>∈</mo><mfenced close="}" open="{"><mrow><mi>c</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mi>D</mi><mi>e</mi><mi>f</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi></mrow></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>C</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>constructor[C]</mtext></mstyle></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>A class cannot be called as a function in ECMAScript.
-Thus, the constructor and type type are only subtype of <literal>Object</literal>:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>T</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>constructor</mtext></mstyle><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>Object</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>Object</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara>If the type argument of the constructor is not a declared type (i.e., a wildcard or a type variable with bounds), the constructor cannot be used in a new expression.
-Thus, the constructor function signature becomes irrelevant for subtype checking.
-In that case, the following rules apply:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><mi>S</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mspace width="3.0mm"/><mi>T</mi><mo>.</mo><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi><mo>.</mo><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>DeclaredTypeWithAccessModifier</mtext></mstyle></mrow><mrow><mstyle mathvariant="monospace"><mtext>constructor</mtext><mtext>S</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>constructor</mtext><mtext>T</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-<simpara>Note that this is only true for the right hand side of the subtyping rule.
-A constructor type with a wildcard is never a subtype of a constructor type without a wildcard.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The figure <xref linkend="cdConstructorClassifierType"/> shows the subtype relations defined by the preceding rules.</simpara>
-<figure xml:id="cdConstructorClassifierType">
-<title>Classifier and Constructor Type Subtype Relations</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_types/fig/cdConstructorClassifierType.svg" width="60%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>cdConstructorClassifierType</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Consequences:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Overriding of static methods is possible and by using the constructor or classifier type, polymorphism for static methods is possible as well.</simpara>
-<example xml:id="_polymorphism-and-static-methods">
-<title>Static Polymorphism</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- static foo(): string { return "A"; }
- static bar(): string { return this.foo(); }
-}
-class B extends A {
- @Override
- static foo(): string { return "B"; }
-}
-
-A.bar(); // will return "A"
-B.bar(); // will return "B", as foo() is called polymorphical</programlisting>
-</example>
-</listitem>
-<listitem>
-<simpara>It is even possible to refer to the constructor of an abstract class.
-The abstract class itself cannot provide this constructor (it only provides a type..), that is to say only concrete subclasses can provide constructors compatible to the constructor.</simpara>
-<example>
-<title>Constructor of Abstract Class</title>
-<programlisting language="n4js" linenumbering="unnumbered">abstract class A {}
-class B extends A {}
-function f(ctor: constructor{A}): A { return new ctor(); }
-
-f(A); // not working: type{A} is not a subtype of constructor{A}.
-f(B); // ok</programlisting>
-</example>
-</listitem>
-</itemizedlist>
-<simpara>Allowing wildcards on constructor type references has pragmatic reasons.
-The usage of constructor references usually indicates very dynamic scenarios.
-In some of these scenarios, e.g., in case of dynamic creation of objects in the context of generic testing or injectors, arbitrary constructors may be used.
-Of course, it won’t be possible to check the correct new expression call in these cases – and using new expressions is prevented by N4JS if the constructor reference contains a wildcard.
-But other constraints, implemented by the client logic, may guarantee correct instantiation via more dynamic constructors, for example via the ECMAScript 2015 reflection API.
-In order to simplify these scenarios and preventing the use of <literal>any</literal>, wildcards are supported in constructors. Since a constructor with a wildcard cannot be used
-in a new expression anyway, using a classifier type is usually better than using a constructor type with wildcard.</simpara>
-<simpara>Using wildcards on classifier types would have the same meaning as using the upper bound directly.
-That is, a type reference <literal>type{? extends C}</literal> can simply be replaced with <literal>type{c}</literal>, and <literal>type{?}</literal> with <literal>type{any}</literal>.</simpara>
-<simpara>To conclude this chapter, let us compare the different types introduced above depending on whether they are used with wildcards or not:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>having a value of type <literal>constructor{C}</literal>, we know we have</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a constructor function of <literal>{C}</literal> or a subclass of <literal>{C}</literal>,</simpara>
-</listitem>
-<listitem>
-<simpara>that can be used for instantiation (i.e. the represented class is not abstract),</simpara>
-</listitem>
-<listitem>
-<simpara>that has a signature compatible to the owned or inherited constructor of <literal>{C}</literal>.</simpara>
-<simpara>This means we have the constructor function of class <literal>{C}</literal> (but only if is non-abstract) or the constructor function of any non-abstract
-subclass of <literal>{C}</literal> with an override compatible signature to that of <literal>{C}</literal>'s constructor function.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>having a value of type <literal>constructor{? extends C}</literal>, we know we have</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a constructor function of <literal>{C}</literal> or a subclass of <literal>{C}</literal>,</simpara>
-</listitem>
-<listitem>
-<simpara>that can be used for instantiation (i.e. the represented class is not abstract).</simpara>
-<simpara>So, same situation as before except that we know nothing about the constructor function’s signature.
-However, if <literal>{C}</literal> has a covariant constructor, cf. <xref linkend="_covariant-constructors"/>, we can still conclude that we have an override compatible
-constructor function to that of <literal>{C}</literal>, because classes with covariant constructors enforce all their subclasses to have override compatible constructors.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>have a value of type <literal>type{? extends C}</literal> or <literal>type{C}</literal> (the two types are equivalent), we know we have:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>an object representing a type (often constructor functions are used for this, e.g. in the case of classes, but could also be a plain object, e.g. in the case of interfaces),</simpara>
-</listitem>
-<listitem>
-<simpara>that represents type <literal>{C}</literal> or a subtype thereof,</simpara>
-</listitem>
-<listitem>
-<simpara>that cannot be used for instantiation (e.g. could be the constructor function of an abstract class, the object representing an interface, etc.).</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</orderedlist>
-<simpara>Slightly simplified, we can say that in the first above case we can always use the value for creating an instance with <literal>new</literal>, in the second case only if the
-referenced type has a covariant constructor, cf. <xref linkend="_covariant-constructors"/>, and never in the third case.</simpara>
-</section>
-<section xml:id="_constructors-and-prototypes-in-ecmascript-2015">
-<title>Constructors and Prototypes in ECMAScript 2015</title>
-<simpara><xref linkend="fig-constructors-and-prototypes"/> for two classes A and B in ECMAScript 2015 shows the constructors, prototypes, and the relations between them for the ECMAScript 2015
-code shown in <xref linkend="ex-constructors-and-prototypes"/>.</simpara>
-<example xml:id="ex-constructors-and-prototypes">
-<title>Constructors and Prototypes</title>
-<programlisting language="javascript" linenumbering="unnumbered">class A {}
-class B extends A {}
-
-var b = new B();</programlisting>
-</example>
-<note>
-<simpara><xref linkend="fig-constructors-and-prototypes"/> shows plain ECMAScript 2015 only.
-Also note that <literal>A</literal> is defined without an <literal>extends</literal> clause, which is what ECMAScript 2015 calls a <emphasis>base class</emphasis> (as opposed to a <emphasis>derived class</emphasis>).
-The constructor of a base class always has Function.prototype as its prototype.
-If we had defined <literal>A</literal> as <literal>class A extends Object {}</literal> in the listing above, then the constructor of <literal>A</literal> would have Object’s constructor as its prototype
-(depicted in as a dashed red arrow), which would make a more consistent overall picture.</simpara>
-</note>
-<figure xml:id="fig-constructors-and-prototypes">
-<title>Constructors and prototypes for two classes A and B in ECMAScript 2015 (not N4JS!)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/04_types/fig/ctorsProtosInES6.svg" align="center"/>
-</imageobject>
-<textobject><phrase>ctorsProtosInES6</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Base classes in the above sense are not available in N4JS.
-If an N4JS class does not provide an <literal>extends</literal> clause, it will implicitly inherit from built-in class <literal>N4Object</literal>,
-if it provides an <literal>extends</literal> clause stating <literal>Object</literal> as its super type, then it corresponds to what is shown in <xref linkend="fig-constructors-and-prototypes"/> with the red dashed arrow.</simpara>
-</section>
-</section>
-<section xml:id="_this-type" role="language-n4js">
-<title>This Type</title>
-<simpara>The <literal>this</literal> keyword may represent either a <literal>this</literal> literal (cf. <xref linkend="ex:this-keyword-and-type-in-instance-and-static-context"/>) or may refer to the <literal>this</literal> type.
-In this section, we describe the latter case.</simpara>
-<simpara>Typical use cases of the <literal>this</literal> type include:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>declaring the return type of instance methods</simpara>
-</listitem>
-<listitem>
-<simpara>declaring the return type of static methods</simpara>
-</listitem>
-<listitem>
-<simpara>as formal parameter type of constructors in conjunction with use-site structural typing</simpara>
-</listitem>
-<listitem>
-<simpara>the parameter type of a function type expression, which appears as type of a method parameter</simpara>
-</listitem>
-<listitem>
-<simpara>the parameter type in a return type expression (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi></math><literal>{this}</literal>,<literal>constructor{this}</literal>)</simpara>
-</listitem>
-<listitem>
-<simpara>an existential type argument inside a return type expression for methods (e.g.<literal>ArrayList<? extends this> method(){…​}</literal>)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The precise rule where it may appear is given below in <xref linkend="Req-IDE-37"/>.</simpara>
-<simpara>The <literal>this</literal> type is similar to a type variable, and it is bound to the declared or inferred type of the receiver.
-If it is used as return type, all return statements of the methods must return the <literal>this</literal> keyword or a variable value implicitly inferred to a <literal>this</literal> type (e.g. <literal>var x = this; return x;</literal>).</simpara>
-<formalpara>
-<title>Simple This Type</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- f(): this {
- return this;
- }
-})
-class B extends A {}
-
-var a: A; var b: B;
-a.f(); // returns something with the type of A
-b.f(); // returns something with the type of B</programlisting>
-</para>
-</formalpara>
-<simpara><literal>this</literal> can be thought of as a type variable which is implicitly substituted with the declaring class (i.e. this type used in a class <literal>{A}</literal> actually means <literal><? extends A></literal>).</simpara>
-<section xml:id="this-type-syntax">
-<title>Syntax</title>
-<programlisting language="xtext" linenumbering="unnumbered">ThisTypeRef returns ThisTypeRef:
- ThisTypeRefNominal | ThisTypeRefStructural;
-
-ThisTypeRefNominal returns ThisTypeRefNominal:
- {ThisTypeRefNominal} 'this'
-;
-
-ThisTypeRefStructural returns ThisTypeRefStructural:
- typingStrategy=TypingStrategyUseSiteOperator
- 'this'
- ('with' '{' ownedStructuralMembers+=TStructMember* '}')?
-;</programlisting>
-<simpara>The keyword <literal>this</literal> and the type expression <literal>this</literal> look similar, however they can refer to different types.
-The type always refers to the type of instances of a class.
-The <literal>this</literal> keyword refers to the type of instances of the class in case of instance methods, but to the classifier the of the class in case of static methods.
-See <xref linkend="_this-keyword"/> for details.</simpara>
-<example xml:id="ex:this-keyword-and-type-in-instance-and-static-context">
-<title>This keyword and type in instance and static context</title>
-<simpara>Note that the following code is not working, because some usages below are
-not valid in N4JS. This is only to demonstrate the types.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- instanceMethod() {
- var c: this = this;
- }
- static staticMethod() {
- var C: type{this} = this;
- }
-}</programlisting>
-</example>
-<simpara>Structural typing and additional members in structural referenced types is described in <xref linkend="_structural-typing"/>.</simpara>
-</section>
-<section xml:id="this-keyword-semantics">
-<title>Semantics</title>
-<requirement xml:id="IDE-37">
-<title>This Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-37" xreflabel="[Req-IDE-37]"/>
-<emphasis role="strong">Requirement: IDE-37:</emphasis>
-<link linkend="Req-IDE-37">This Type</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>this</literal> used in the context of a class is actually inferred to an existential type <literal>? extends A</literal> inside the class itself.</simpara>
-</listitem>
-<listitem>
-<simpara>the <literal>this</literal> type may only be used</simpara>
-<itemizedlist>
-<listitem>
-<simpara>as the type of a formal parameter of a constructor, if and only if combined with use-site structural typing.</simpara>
-</listitem>
-<listitem>
-<simpara>at covariant positions within member declarations, except for static members of interfaces.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>Remarks</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Due to the function subtype relation and constraints on overriding methods (in which the overriding method has to be a subtype of the overridden method),
-it is not possible to use the <literal>this</literal> type in formal parameters but only as return type. The following listing demonstrates that problem:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- bar(x: this): void { ... } // error
- // virtually defines: bar(x: A): void
-}
-class B extends A {
- // virtually defines: bar(x: B): void
-}</programlisting>
-<simpara>As the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> type is replaced similar to a type variable, the virtually defined method <literal>bar</literal> in is not override compatible with <literal>bar</literal> in <literal>A</literal>.</simpara>
-<simpara>In case of constructors, this problem does not occur because a subclass constructor does not need to be override compatible with the constructor of the super class.
-Using <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> as the type of a constructor’s parameter, however, would mean that you can only create an instance of the class if you already have
-an instance (considering that due to the lack of method overloading a class can have only a single constructor), making creation of the first instance impossible.
-Therefore, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> is also disallowed as the type of a constructor’s parameter.</simpara>
-</listitem>
-<listitem>
-<simpara>The difference between the type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> and the keyword <literal>this</literal> is when and how theactual type is set:
-the actual type of the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> type is computed at compile(or validation) time and is always the containing type (of the member in which the type expression is used)
-or a subtype of that type – this isnot a heuristic, this is so by definition.
-In contrast, the actual typeof the keyword <literal>this</literal> is only available at runtime, while the type used at compilation time is only a heuristically-computed type, in other words,a good guess.</simpara>
-</listitem>
-<listitem>
-<simpara>The value of the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> type is, in fact, not influenced by any <literal>@This</literal> annotations.
-Instead of using <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> in these cases, the type expressions in the <literal>@This</literal> annotations can be used.</simpara>
-</listitem>
-<listitem>
-<simpara>The <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> type is always bound to the instance-type regardless of the context it occurs in (non-static or static).
-To refer to the this-classifier (static type) the construct <literal>type{this}</literal> is used.</simpara>
-</listitem>
-</itemizedlist>
-<simpara><?asciidoc-pagebreak?></simpara>
-<example>
-<title>This type in function-type-expression</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- alive: boolean = true;
- methodA(func: {function(this)}): string {
- func(this); // applying the passed-in function
- return "done";
- }
-}</programlisting>
-</example>
-<simpara>The use of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi></math> type is limited to situations where it cannot be referred in mixed co- and contra-variant ways.
-In the following example the problem is sketched up. <footnote><simpara>The phenomenon is described in IDEBUG-263</simpara></footnote></simpara>
-<example>
-<title>Problems with this type and type arguments</title>
-<programlisting language="n4js" linenumbering="unnumbered">// Non-working example, see problem in line 15.
-class M<V> { public value: V; }
-class A {
- public store: M<{function(this)}>; // usually not allowed, but let's assume it would be possible----
-}
-class B extends A { public x=0; } // type of store is M<{function(B)}>
-
-var funcA = function(a: A) {/*...something with a...*/}
-var funcB = function(b: B) { console.log(b.x); }
-var a: A = new A(); var b: B = new B();
-b.store.value = funcA // OK, since {function(A)} <: {function(B)}
-b.store.value = funcB // OK.
-
-var a2: A = b; // OK, since B is a subtype of A
-a2.store.value( a ) // RUNTIME ERROR, the types are all correct, but remember b.store.value was assigned to funcB, which can only handle subtypes of B!</programlisting>
-</example>
-</section>
-</section>
-<section xml:id="_enums" role="language-n4js">
-<title>Enums</title>
-<simpara>Enums are an ordered set of literals.
-Although enums are not true classes, they come with built-in methods for accessing value, name and type name of the enum.</simpara>
-<simpara>In N4JS, two flavours of enumerations are distinguished: ordinary enums (N4JS) and string based enums.
-Ordinary enums (or in short, enums) are used while programming in N4JS.
-String based enums are introduced to access enumerations derived from standards, mainly developed by the W3C, in order to access the closed set of string literals defined in webIDL syntax.</simpara>
-<section xml:id="_enums-n4js">
-<title>Enums (N4JS)</title>
-<simpara>Definition and usage of an enumeration:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">// assume this file to be contained in a package "myPackage"
-enum Color {
- RED, GREEN, BLUE
-}
-
-enum Country {
- DE : "276",
- US : "840",
- TR : "792"
-}
-
-var red: Color = Color.RED;
-var us: Country = Country.US;
-
-console.log(red.name); // --> RED
-console.log(red.value); // --> RED
-console.log(red.n4class.fqn); // --> myPackage.Color
-console.log(red.toString()); // --> RED
-
-console.log(us.name); // --> US
-console.log(us.value); // --> 840
-console.log(us.n4classfqn); // --> myPackage.Country
-console.log(us.toString()); // --> 840</programlisting>
-<section xml:id="enums-syntax">
-<title>Syntax</title>
-<programlisting language="xtext" linenumbering="unnumbered">N4EnumDeclaration <Yield>:
- =>( {N4EnumDeclaration}
- (declaredModifiers+=N4Modifier)*
- 'enum' name=BindingIdentifier<Yield>? )
- '{'
- (literals+=N4EnumLiteral (',' literals+=N4EnumLiteral)*)?
- '}';
-
-N4EnumLiteral: name=IdentifierName (':' value=STRING)?;</programlisting>
-</section>
-<section xml:id="enums-semantics" role="language-n4js">
-<title>Semantics</title>
-<simpara>The enum declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math> is of type <literal>type{E}</literal> and every enumeration is implicitly derived from <literal>N4Enum</literal>.
-There are similarities to other languages such as Java, for example, where the literals of an enum are treated as final static fields with the type
-of the enumeration and the concrete enumeration provides specific static methods including the literals.
-This leads to the following typing rules:</simpara>
-<requirement xml:id="IDE-38">
-<title>Enum Type Rules</title>
-<simpara>
-<anchor xml:id="Req-IDE-38" xreflabel="[Req-IDE-38]"/>
-<emphasis role="strong">Requirement: IDE-38:</emphasis>
-<link linkend="Req-IDE-38">Enum Type Rules</link> (ver. 1)</simpara>
- <simpara>
-
-For a given enumeration declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math> with literals <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math>, the following type rules are defined:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Every enumeration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math> is a subtype of the base type <literal>N4Enum</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>E</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>N</mi><mn>4</mn><mi>E</mi><mi>n</mi><mi>u</mi><mi>m</mi></mrow></mfrac><mrow/></math>
-<simpara>which itself is a subtype of <literal>Object</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>N</mi><mn>4</mn><mi>E</mi><mi>n</mi><mi>u</mi><mi>m</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>O</mi><mi>b</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>Every literal <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math> of an enumeration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math> is
-of the type of the enumeration:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>L</mi><mo>∈</mo><mi>E</mi><mo>.</mo><mi>l</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>s</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>L</mi><mi>:</mi><mi>E</mi></mrow></mfrac></math>
-</listitem>
-</orderedlist>
-<simpara>This means that every literal is a subtype of <literal>N4Enum</literal> and <literal>Object</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>L</mi><mo>∈</mo><mi>E</mi><mo>.</mo><mi>l</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>s</mi></mrow><mrow><mi>L</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>N</mi><mn>4</mn><mi>E</mi><mi>n</mi><mi>u</mi><mi>m</mi><mo>∧</mo><mi>L</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>O</mi><mi>b</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi></mrow></mfrac></math>
-<simpara>The base enumeration type <literal>N4Enum</literal> is defined as follows:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/**
- * Base class for all enumeration, literals are assumed to be static constant fields of concrete subclasses.
- */
-public object N4Enum {
-
- /**
- * Returns the name of a concrete literal
- */
- public get name(): string
-
- /**
- * Returns the value of a concrete literal. If no value is
- * explicitly set, it is similar to the name.
- */
- public get value(): string
-
- /**
- * Returns a string representation of a concrete literal, it returns
- * the same result as value()
- */
- public toString(): string
-
- /**
- * Returns the meta class object of this enum literal for reflection.
- * The very same meta class object can be retrieved from the enumeration type directly.
- */
- public static get n4type(): N4EnumType
-
- //IDE-785 this as return type in static
-
- /**
- * Returns array of concrete enum literals
- */
- public static get literals(): Array<? extends this>
-
- /**
- * Returns concrete enum literal that matches provided name,
- * if no match found returns undefined.
- */
- public static findLiteralByName(name: string): this
-
- /**
- * Returns concrete enum literal that matches provided value,
- * if no match found returns undefined.
- */
- public static findLiteralByValue (value: string): this
-}</programlisting>
-</requirement>
-<requirement xml:id="IDE-39">
-<title>Unique literal names</title>
-<simpara>
-<anchor xml:id="Req-IDE-39" xreflabel="[Req-IDE-39]"/>
-<emphasis role="strong">Requirement: IDE-39:</emphasis>
-<link linkend="Req-IDE-39">Unique literal names</link> (ver. 1)</simpara>
- <simpara>
-
-* <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>i</mi><mo>,</mo><mi>j</mi><mi>:</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>s</mi><mfenced close="]" open="["><mi>i</mi></mfenced><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>l</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>s</mi><mfenced close="]" open="["><mi>j</mi></mfenced><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>⇔</mo><mi>i</mi><mo>=</mo><mi>j</mi></math></simpara>
-<simpara>Literal names have to be unique.</simpara>
-</requirement>
-<requirement xml:id="IDE-40">
-<title>Enum Literals are Singletons</title>
-<simpara>
-<anchor xml:id="Req-IDE-40" xreflabel="[Req-IDE-40]"/>
-<emphasis role="strong">Requirement: IDE-40:</emphasis>
-<link linkend="Req-IDE-40">Enum Literals are Singletons</link> (ver. 1)</simpara>
- <simpara>
-
-Enum literals are singletons:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><msub><mi>e</mi><mn>1</mn></msub><mo>,</mo><msub><mi>e</mi><mn>2</mn></msub><mo>,</mo><mi>μ</mi><mfenced close=")" open="("><msub><mi>e</mi><mn>1</mn></msub></mfenced><mo>=</mo><mi>μ</mi><mfenced close=")" open="("><msub><mi>e</mi><mn>2</mn></msub></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>N4EnumLiteral</mtext></mstyle><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><msub><mi>e</mi><mn>1</mn></msub><mo>=</mo><mi>Γ</mi><mo>⊢</mo><msub><mi>e</mi><mn>2</mn></msub><mi>:</mi><msub><mi>e</mi><mn>1</mn></msub><mo>=</mo><mo>=</mo><msub><mi>e</mi><mn>2</mn></msub><mo>⇔</mo><msub><mi>e</mi><mn>1</mn></msub><mo>=</mo><mo>=</mo><mo>=</mo><msub><mi>e</mi><mn>2</mn></msub></math>
-</requirement>
-<example>
-<title>Enumeration List</title>
-<simpara>Due to the common base type <literal>N4Enum</literal> it is possible to define generics accepting only enumeration, as shown in this example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">enum Color { R, G, B}
-
-class EList<T extends N4Enum> {
- add(t: T) {}
- get(): T { return null; }
-}
-
-var colors: EList<Color>;
-colors.add(Color.R);
-var c: Color = colors.get();</programlisting>
-</example>
-</section>
-</section>
-<section xml:id="_string-based-enums">
-<title>String-Based Enums</title>
-<simpara>In current web standards [<link linkend="W3C:Steen:14:XL">W3C:Steen:14:XL</link>], definitions of enumerations are often given in webIDL syntax.
-While the webIDL-definition assembles a set of unique string literals as a named enum-entity, the language binding to ECMAScript refers to the usage of the members of these enumerations only.
-Hence, if an element of an enumeration is stored in a variable or field, passed as a parameter into a method or function or given back as a result, the actual type in JavaScript will be <literal>string</literal>.
-To provide the N4JS user with some validations regarding the validity of a statement at compile time, a special kind of subtypes of <literal>string</literal> are introduced: the string-based enum using the <literal>@StringBased</literal> annotation.
-(See also other string-based types like <literal>typename<T></literal> <literal>pathSelector<T></literal> and <literal>i18nKey</literal> in <xref linkend="_primitive-pathselector-and-i18nkey"/>.)</simpara>
-<simpara>String-based enums do not have any kind of runtime representation; instead, the transpiler will replace each reference to a literal of a string-based enum by a corresponding string literal in the output code.
-Furthermore, no meta-information is available for string-based enums, i.e. the <literal>n4type</literal> property is not available.
-The only exception is the static getter <literal>literals</literal>: it is available also for string-based enums and has the same meaning.
-In case of string-based enums, however, there won’t be a getter used at runtime; instead, the transpiler replaces every read access to this getter by an array literal containing a string literal for each of the enum’s literals.</simpara>
-<requirement xml:id="IDE-41">
-<title>String-Based Enum Type Rules</title>
-<simpara>
-<anchor xml:id="Req-IDE-41" xreflabel="[Req-IDE-41]"/>
-<emphasis role="strong">Requirement: IDE-41:</emphasis>
-<link linkend="Req-IDE-41">String-Based Enum Type Rules</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For a string-based enum declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>E</mi><mi>S</mi></msub></math> with literals <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>L</mi><mi>S</mi></msub></math> the following type rules are defined:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Every string-based enumeration <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>E</mi><mi>S</mi></msub></math> is a subtype of the base type <literal>N4StringBasedEnum</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><msub><mi>E</mi><mi>S</mi></msub></mfenced><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>N4StringBasedEnum</mtext></mstyle></mrow></mfrac><mrow/></math>
-<simpara>which itself is not related to the standard enumeration type <literal>N4Enum</literal></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>N4StringBasedEnum</mtext></mstyle><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>N4Enum</mtext></mstyle></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>N4Enum</mtext></mstyle><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>N4StringBasedEnum</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara><literal>N4StringBasedEnum</literal> is a subtype of <literal>string</literal></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>N4StringBasedEnum</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara>Each literal in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>L</mi><mi>S</mi></msub></math> of a string-based enumeration
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>E</mi><mi>S</mi></msub></math> is of the type of the string-based enumeration.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>l</mi><mo>∈</mo><msub><mi>E</mi><mi>S</mi></msub><mo>.</mo><msub><mi>L</mi><mi>S</mi></msub></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><msub><mi>E</mi><mi>S</mi></msub></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara><xref linkend="Req-IDE-39"/> also applies for <literal>N4StringBasedEnum</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara><xref linkend="Req-IDE-40"/> also applies for <literal>N4StringBasedEnum</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>References to string-based enums may only be used in the following places:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>in type annotations</simpara>
-</listitem>
-<listitem>
-<simpara>in property access expressions to refer to one of the enum’s literals</simpara>
-</listitem>
-<listitem>
-<simpara>in property access expressions to read from the static getter <literal>literals</literal></simpara>
-<simpara>In particular, it is invalid to use the type of a string-based enum as a
-value, as in</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> @StringBased enum Color { RED, GREEN, BLUE }
- var c = Color;</programlisting>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-<example>
-<title>WebIDL example</title>
-<formalpara>
-<title>Gecko-Engine webIDL XMLHttpRequestResponseType as taken from [<link linkend="W3C:Steen:14:XL">W3C:Steen:14:XL</link>]</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">enum XMLHttpRequestResponseType {
- "",
- "arraybuffer",
- "blob",
- "document",
- "json",
- "text" //, ... and some mozilla-specific additions
-}</programlisting>
-</para>
-</formalpara>
-<simpara>Compatible Definition of this Enumeration in N4JS, provided through a
-runtime-library definition:</simpara>
-<formalpara>
-<title>File in source-folder: w3c/dom/XMLHttpRequestResponseType.n4js</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">@StringBased enum XMLHttpRequestResponseType {
- vacant : "",
- arrayBuffer : "arraybuffer",
- blob : "blob",
- document : "document",
- json : "json",
- text : "text"
- }</programlisting>
-</para>
-</formalpara>
-<simpara>Usage of the enumeration in the definition files of the runtime-library.
-Note the explicit import of the enumeration.</simpara>
-<formalpara>
-<title>XMLHttpRequestResponse.n4jsd</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">@@ProvidedByRuntime
-import XMLHttpRequestResponseType from "w3c/dom/XMLHttpRequestResponseType";
-@Global
-export external public class XMLHttpRequestResponse extends XMLHttpRequestEventTarget {
- // ...
- // Setter Throws TypeError Exception
- public responseType: XMLHttpRequestResponseType;
- // ...
-}</programlisting>
-</para>
-</formalpara>
-<simpara>Client code importing the runtime-library as defined above can now use the Enumeration in a type-safe way:</simpara>
-<formalpara>
-<title>String-Based Enumeration Usage</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">import XMLHttpRequestResponseType from "w3c/dom/XMLHttpRequestResponseType";
-
-public function process(req: XMLHttpRequest) : void {
- if( req.responseType == XMLHttpRequestResponseType.text ) {
- // do stuff ...
- } else {
- // signal unrecognized type.
- var errMessage: req.responseType + " is not supported"; // concatination of two strings.
- show( errMessage );
- }
-}</programlisting>
-</para>
-</formalpara>
-</example>
-</requirement>
-</section>
-</section>
-<section xml:id="_short-hand-syntax" role="language-n4js">
-<title>Short-Hand Syntax</title>
-<simpara>Short-hand syntax is available for a number of built-in types.</simpara>
-<section xml:id="_array-short-hand-syntax">
-<title>Array Short-Hand Syntax</title>
-<simpara>For the built-in type <literal>Array</literal> a convenience short form is available. Thus, writing</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let arr: string[];</programlisting>
-<simpara>is equivalent to</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let arr: Array<string>;</programlisting>
-<simpara>Multi-dimensional arrays can be declared as such:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let arr: string[][][];</programlisting>
-<simpara>which is equivalent to</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let arr: Array<Array<Array<string>>>;</programlisting>
-</section>
-<section xml:id="_iterablen-short-hand-syntax">
-<title>IterableN Short-Hand Syntax</title>
-<simpara>The built-in IterableN types (i.e. <literal>Iterable2</literal>, <literal>Iterable3</literal>, …​ <literal>Iterable9</literal>, see <xref linkend="IterableN"/>) are
-also provided with a short-hand syntax. For example, writing</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let i3: [string,number,string[]];</programlisting>
-<simpara>would be equivalent to</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let i3: Iterable3<string,number,Array<string>>;</programlisting>
-<simpara>Note the following special cases:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let i0: [];
-let i1: [string];
-let union: string|number[];</programlisting>
-<simpara>which is equivalent to</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">let i0: Iterable<?>;
-let i1: Iterable<string>;
-let union: union{string,Array<number>}; // not: Array<union{string,number}></programlisting>
-<simpara>Further note: while this syntax is very similar to TypeScript’s tuple syntax, the semantics
-of tuples and IterableN are very different.</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_classifiers">
-<title>Classifiers</title>
-<section xml:id="_n4js-specific-classifiers">
-<title>N4JS Specific Classifiers</title>
-<simpara>N4JS provides three new metatypes: class, interface, and enums.
-In this section we describe classes and interfaces.
-These metatypes, called <emphasis>classifiers</emphasis>, share some common properties which are described before type specific properties are outlined in the following sections.</simpara>
-<simpara>All of these metatypes can be marked with type access modifiers:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">enum N4JSTypeAccessModifier: project | public;</programlisting>
-<section xml:id="_properties-2" role="language-n4js">
-<title>Properties</title>
-<simpara><emphasis role="strong">Properties defined by syntactic elements:</emphasis></simpara>
-<variablelist>
-<varlistentry>
-<term><literal>annotations</literal> </term>
-<listitem>
-<simpara>Arbitrary annotations, see <xref linkend="_annotations"/> for details.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>accessModifier</literal> </term>
-<listitem>
-<simpara>N4JS type access modifier: <literal>public</literal>, or <literal>project</literal>; <literal>public</literal> can be combined with <literal>@Internal</literal>; if
-<emphasis role="strong">export</emphasis> is <literal>true</literal> the default is else the default is <literal>private</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>name</literal> </term>
-<listitem>
-<simpara>The simple name of a classifier. If the classifier is defined by an anonymous class expression, an artificial but unique name is created.
-The name needs to be a valid identifier, see <xref linkend="_valid-names"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>typePars</literal> </term>
-<listitem>
-<simpara>Collection of type parameters of a generic classifier; empty by default.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>ownedMembers</literal> </term>
-<listitem>
-<simpara>Collection of owned members, i.e. methods and fields defined directly in the classifier and, if present, the explicitly defined constructor.
-Depending on the concrete classifier, additional constraints are defined.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>typingStrategy</literal> </term>
-<listitem>
-<simpara>The definition-site typing strategy. By default nominal typing is used.
-See <xref linkend="_structural-typing"/> for details.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara><emphasis role="strong">The following pseudo properties are defined via annotations:</emphasis></simpara>
-<variablelist>
-<varlistentry>
-<term><literal>export</literal> </term>
-<listitem>
-<simpara>Boolean property set to true if the <literal>export</literal> modifier is set.
-If value is true, the classifier may be accessible outside the project.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>final</literal> </term>
-<listitem>
-<simpara>Boolean property which is set to final if annotation <literal>@Final</literal> is set.
-Also see <xref linkend="_final-modifier"/></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>deprecated</literal> </term>
-<listitem>
-<simpara>Boolean property set to true if annotation <literal>@Deprecated</literal> is set.</simpara>
-<note>
-<simpara>Version 0.4, not implemented in Version 0.3</simpara>
-</note>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara><emphasis role="strong">We additionally define the following pseudo properties:</emphasis></simpara>
-<variablelist>
-<varlistentry>
-<term><literal>acc</literal> </term>
-<listitem>
-<simpara>Type access modifier as described in <xref linkend="_accessibility-of-types-top-level-variables-and-function-declarations"/>, it is the aggregated value of the
-<literal>accessModifier</literal> and the <emphasis role="strong">export</emphasis> property.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>owned{Fields|Methods|Getters|Setters|Accessors}</literal> </term>
-<listitem>
-<simpara>Filters ownedMembers by metatype, short for<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>x</mi><mo>∈</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>μ</mi><mfenced close=")" open="("><mi>x</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle></math> etc.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>members</literal> </term>
-<listitem>
-<simpara>Reflexive transitive closure of all members of a classifier and its super classifiers, see <xref linkend="_common-semantics-of-classifiers"/> on how this is calculated.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fields|methods|getters|setters|accessors</literal> </term>
-<listitem>
-<simpara>Filters members by metatype, short for<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>x</mi><mo>∈</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>μ</mi><mfenced close=")" open="("><mi>x</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle></math> etc.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>superClassifiers</literal> </term>
-<listitem>
-<simpara>Classes and interface may extend or implement classes or interfaces.
-Any class or interface extended or interface implemented is called <emphasis>super classifier</emphasis>.
-We distinguish the directly subtyped classifiers and from the transitive closure of supertypes <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><msup><mi>s</mi><mo>*</mo></msup></math></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_common-semantics-of-classifiers" role="language-n4js">
-<title>Common Semantics of Classifiers</title>
-<requirement xml:id="IDE-42">
-<title>Subtyping of Classifiers</title>
-<simpara>
-<anchor xml:id="Req-IDE-42" xreflabel="[Req-IDE-42]"/>
-<emphasis role="strong">Requirement: IDE-42:</emphasis>
-<link linkend="Req-IDE-42">Subtyping of Classifiers</link> (ver. 1)</simpara>
- <simpara>
-
-For a given type <literal>C</literal>, and supertypes <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>=</mo><mfenced close="}" open="{"><msub><mi>S</mi><mn>1</mn></msub><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><msub><mi>S</mi><mi>n</mi></msub></mfenced></math> directly subtyped
-<literal>C</literal>, the following constraints must be true:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The supertypes must be accessible to the subtype:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>S</mi><mi>n</mi></msub></math> must be accessible to <literal>C</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>All type parameters of the direct supertypes have to be bound by type arguments in the subtype and the type arguments have to be substitutable types of the type parameters.</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mn>0</mn><mo><</mo><mi>i</mi><mo>≤</mo><mi>k</mi><mi>:</mi><mo>∀</mo><mi>P</mi><mo>∈</mo><msub><mi>S</mi><mi>i</mi></msub><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∃</mo><mi>A</mi><mo>∈</mo><msub><mi>C</mi><mo>.</mo></msub><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><mi>g</mi><mi>s</mi><mi>:</mi><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mi>A</mi><mi>P</mi></mfenced><mo>∧</mo><mi>A</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mo><</mo><mi>:</mi><mi>P</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Wildcards may not be used as type argument when binding a supertype’s type parameters.</simpara>
-</listitem>
-<listitem>
-<simpara>A classifier cannot be directly subtyped directly multiple times:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><msub><mi>S</mi><mi>i</mi></msub><mo>,</mo><msub><mi>S</mi><mi>j</mi></msub><mfenced close=")" open="("><mi>i</mi><mrow><mi>j</mi><mo>∈</mo><mfenced close="}" open="{"><mrow><mn>1.</mn><mo>.</mo><mi>n</mi></mrow></mfenced></mrow></mfenced><mi>:</mi><msub><mi>S</mi><mi>i</mi></msub><mo>=</mo><msub><mi>S</mi><mi>j</mi></msub><mo>→</mo><mi>i</mi><mo>=</mo><mi>j</mi></math></simpara>
-</listitem>
-</orderedlist>
-<simpara>In order to simplify the following constraints, we use the pseudo property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math> to refer to all members of a classifier.
-This includes all members directly declared by the classifier itself, i.e. the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi></math>, and all members inherited from its super classifiers.
-The concrete mechanisms for inheriting a member are different and further constraint (cf. <xref linkend="_redefinition-of-members"/>).
-A classifier only inherits its members from its direct supertypes, although the supertypes may contains members inherited from their supertypes.</simpara>
-</requirement>
-</section>
-<section xml:id="_classes" role="language-n4js">
-<title>Classes</title>
-<section xml:id="_definition-of-classes">
-<title>Definition of Classes</title>
-<simpara>Classes are either declared with a class declaration on top level, or they can be used as anonymous classes in expressions.
-The latter may have a name, which may be used for error messages and reflection.</simpara>
-<simpara>At the current stage, class expressions are effectively disabled at least until the semantics of them are finalized in ECMAScript 6.</simpara>
-<simpara>In N4JS (as in many other languages) multi-inheritance of classes is not supported.
-Although the <literal>diamond problem</literal> (of functions being defined in both superclasses) could be solved via union and intersection types, this would lead to problems when calling these super implementations.
-This is particularly an issue due to JavaScript not supporting
-multiple prototypes.<footnote><simpara>E.g., for given <literal role="language-n4js">class A{ foo(A):A{}} class B{ foo(B):B{}}</literal>, a class C could be defined as <literal role="language-n4js">class C{ foo(union{A,B}):intersection{A,B}{}}</literal>. In this case it would then be a syntactical problem (and even worse - a conceptual problem) of how to call the super methods defined in A and Bfrom C.</simpara></footnote>
-Interfaces, however, allow for multi-inheritance. Since the former can also define functions with bodies, this is not a hard restriction.</simpara>
-<section xml:id="class-syntax">
-<title>Syntax</title>
-<formalpara>
-<title>Syntax N4 Class Declaration and Expression</title>
-<para>
-<programlisting language="xtext" linenumbering="unnumbered">N4ClassDeclaration <Yield>:
- =>(
- {N4ClassDeclaration}
- annotations+=Annotation*
- (declaredModifiers+=N4Modifier)*
- 'class' typingStrategy=TypingStrategyDefSiteOperator? name=BindingIdentifier<Yield>?
- )
- TypeVariables?
- ClassExtendsClause<Yield>?
- Members<Yield>
-;
-
-N4ClassExpression <Yield>:
- {N4ClassExpression}
- 'class' name=BindingIdentifier<Yield>?
- ClassExtendsClause<Yield>?
- Members<Yield>;
-
-
-fragment ClassExtendsClause <Yield>*:
- 'extends' (
- =>superClassRef=ParameterizedTypeRefNominal ('implements' ClassImplementsList)?
- | superClassExpression=LeftHandSideExpression<Yield>
- )
- | 'implements' ClassImplementsList
-;
-
-fragment ClassImplementsList*:
- implementedInterfaceRefs+=ParameterizedTypeRefNominal
- (',' implementedInterfaceRefs+=ParameterizedTypeRefNominal)*
-;
-
-fragment Members <Yield>*:
- '{'
- ownedMembers+=N4MemberDeclaration<Yield>*
- '}'
-;</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="class-properties">
-<title>Properties</title>
-<simpara>These are the properties of class, which can be specified by the user:
-Syntax N4 Class Declaration and Expression</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>abstract</literal> </term>
-<listitem>
-<simpara>Boolean flag indicating whether class may be instantiable; default is <literal>false</literal>, see <xref linkend="_abstract-classes"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>external</literal> </term>
-<listitem>
-<simpara>Boolean flag indicating whether class is a declaration without implementation or with an external (non-N4JS) implementation; default is <literal>false</literal>, see <xref linkend="_definition-site-structural-typing"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>defStructural</literal> </term>
-<listitem>
-<simpara>Boolean flag indicating whether subtype relation uses nominal or structural typing, see <xref linkend="_definition-site-structural-typing"/> for details.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>superType/sup</literal> </term>
-<listitem>
-<simpara>The type referenced by <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math> is called direct superclass of a class, and vice versa the class is a direct subclass of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math>.
-Instead of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math>, we sometimes simply write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><mi>p</mi></math>.
-The derived set <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>u</mi><msup><mi>p</mi><mo>+</mo></msup></math> is defined as the transitive closures of all direct and indirect superclasses of a class.
-If no supertype is explicitly stated, classes are derived from <literal>N4Object</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>implementedInterfaces</literal>/<literal>interfaces</literal> </term>
-<listitem>
-<simpara>Collection of interfaces directly <emphasis>implemented</emphasis> by the class; empty by default.
-Instead of <literal>implementedInterfaces</literal>, we simply write <literal>interfaces</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>ownedCtor</literal> </term>
-<listitem>
-<simpara>Explicit constructor of a class (if any), see <xref linkend="_constructor-and-classifier-type"/>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>And we additionally define the following pseudo properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>ctor</literal> </term>
-<listitem>
-<simpara>Explicit or implicit constructor of a class, see <xref linkend="_constructor-and-classifier-type"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fields</literal> </term>
-<listitem>
-<simpara>Further derived properties for retrieving all methods (property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi></math>), fields (property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi></math>), static
-members (property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>O</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math>), etc. can easily be added by filtering properties <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math> or <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="class-type-inference">
-<title>Type Inference</title>
-<simpara>The type of a class declaration or class expression <literal>C</literal> (i.e., a class definition in general) is of type <literal>constructor{C}</literal> if it is not abstract,
-that is if it can be instantiated.
-If it is abstract, the type of the definition simply is <literal>type{C}</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><mo>¬</mo><mi>C</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>C</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>constructor</mtext></mstyle><mfenced close="}" open="{"><mi>C</mi></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>C</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>C</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><mi>C</mi></mfenced></mrow></mfrac></mtd></mtr></mtable></math>
-<requirement xml:id="IDE-43">
-<title>Structural and Nominal Supertypes</title>
-<simpara>
-<anchor xml:id="Req-IDE-43" xreflabel="[Req-IDE-43]"/>
-<emphasis role="strong">Requirement: IDE-43:</emphasis>
-<link linkend="Req-IDE-43">Structural and Nominal Supertypes</link> (ver. 1)</simpara>
- <simpara>
-
-The type of supertypes and implemented interfaces is always the nominal type, even if the supertype is declared structurally.</simpara>
-
-</requirement>
-</section>
-</section>
-<section xml:id="class-semantics">
-<title>Semantics</title>
-<simpara>This section deals with the (more or less) type-independent constraints on classes.</simpara>
-<simpara>Class expressions are not fully supported at the moment.</simpara>
-<definition>
-<title>Transitive closure of members</title>
-<simpara>
-<anchor xml:id="transitive_closure_of_members" xreflabel="[transitive_closure_of_members]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="transitive_closure_of_members">Transitive closure of members</link></simpara>
-<simpara>
-
-The reflexive transitive closure of members of a class is indirectly defined by the override and implementation constraints defined in <xref linkend="_redefinition-of-members"/>.</simpara>
-<simpara>Note that since overloading is forbidden, the following constraint is true <footnote><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>o</mi><mi>r</mi><mi>P</mi><mi>a</mi><mi>i</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>m</mi><mn>1</mn></msub><msub><mi>m</mi><mn>2</mn></msub></mfenced></math> is defined as follows: <math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close=")" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><msub><mi>m</mi><mn>1</mn></msub></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>getter</mtext></mstyle><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><msub><mi>m</mi><mn>2</mn></msub></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>setter</mtext></mstyle></mrow></mfenced><mo>∨</mo><mfenced close=")" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><msub><mi>m</mi><mn>1</mn></msub></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>setter</mtext></mstyle><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><msub><mi>m</mi><mn>2</mn></msub></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>getter</mtext></mstyle></mrow></mfenced></math></simpara></footnote>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><msub><mi>m</mi><mn>1</mn></msub><mo>,</mo><msub><mi>m</mi><mn>2</mn></msub><mo>∈</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>⇔</mo><msub><mi>m</mi><mn>1</mn></msub><mo>=</mo><msub><mi>m</mi><mn>2</mn></msub><mo>∨</mo><mi>a</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>o</mi><mi>r</mi><mi>P</mi><mi>a</mi><mi>i</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>m</mi><mn>1</mn></msub><msub><mi>m</mi><mn>2</mn></msub></mfenced></math>
-<simpara>Remarks: Class and method definition is quite similar to the proposed ECMAScript version 6 draft [<link linkend="ECMA15a">ECMA15a(p.S13.5)</link>], except that an N4 class and members may contain</simpara>
-<itemizedlist>
-<listitem>
-<simpara>annotations, abstract and access modifiers</simpara>
-</listitem>
-<listitem>
-<simpara>fields</simpara>
-</listitem>
-<listitem>
-<simpara>types</simpara>
-</listitem>
-<listitem>
-<simpara>implemented interfaces</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Note that even <literal>static</literal> is used in ECMAScript 6.</simpara>
-</definition>
-<simpara>Mixing in members (i.e. interface’s methods with default implementation or fields) is similar to mixing in members from roles as defined in [<link linkend="Dart13a">Dart13a(p.S9.1)</link>].
-It is also similar to default implementations in Java 8 [<link linkend="Gosling15a">Gosling15a</link>].
-In Java, however, more constraints exist, (for example, methods of interfaces must be public).</simpara>
-<example>
-<title>Simple Class</title>
-<simpara>This first example shows a very simple class with a field, a constructor and a method.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- data: any;
-
- constructor(data: any) {
- this.data = data;
- }
-
- foo(): void { }
-}</programlisting>
-</example>
-<example>
-<title>Extend and implement</title>
-<simpara>The following example demonstrate how a class can extend a superclass and implement an interface.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface I {
- foo(): void
-}
-class C{}
-class X extends C implements I {
- @Override
- foo(): void {}
-}</programlisting>
-</example>
-<simpara>A class <literal>C</literal> is a subtype of another classifier <literal>S</literal> (which can be a class or interface) if the other classifier <literal>S</literal> is (transitively) contained in the supertypes (superclasses or implemented interfaces) of the class:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>=</mo><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>TClass</mtext></mstyle><mi> </mi><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mfenced close="]" open="["><mrow><mi>T</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi></mrow></mfenced><mi> </mi><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></mfrac><mfenced close="]" open="["><mrow><mi>s</mi><mi>h</mi><mi>o</mi><mi>r</mi><mi>t</mi><mi>c</mi><mi>u</mi><mi>t</mi></mrow></mfenced><mtext>
-</mtext></math>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>TClass</mtext></mstyle><mi> </mi><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mfenced close="]" open="["><mrow><mi>T</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi></mrow></mfenced><mi> </mi><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></mfrac></math>
-<requirement xml:id="IDE-44">
-<title>Implicit Supertype of Classes</title>
-<simpara>
-<anchor xml:id="Req-IDE-44" xreflabel="[Req-IDE-44]"/>
-<emphasis role="strong">Requirement: IDE-44:</emphasis>
-<link linkend="Req-IDE-44">Implicit Supertype of Classes</link> (ver. 1)</simpara>
- <simpara>
-
-1. The implicit supertype of all classes is <literal>N4Object</literal>.
-All classes with no explicit supertype are inherited from <literal>N4Object</literal>.
-2. If the supertype is explicitly set to <literal>Object</literal>, then the class is not derived from <literal>N4Object</literal>.
-Meta-information is created similar to an <literal>N4Object</literal>-derived class.
-Usually, there is no reason to explicitly derive a class from <literal>Object</literal>.
-3. External classes are implicitly derived from , unless they are annotated with <literal>@N4JS</literal>(cf.<xref linkend="_external-declarations"/>).</simpara>
-</requirement>
-</section>
-<section xml:id="_final-modifier">
-<title>Final Modifier</title>
-<simpara>Extensibility refers to whether a given classifier can be subtyped.
-Accessibility is a prerequisite for extensibility.
-If a type cannot be seen, it cannot be subclassed.
-The only modifier influencing the extensibility directly is the annotation <literal>@Final</literal>, which prevents all subtyping.
-The following table shows how to prevent other projects or vendors from subtyping by also restricting the accessibility of the constructor:</simpara>
-<table frame="all" rowsep="1" colsep="1">
-<title>Extensibility of Types</title>
-<tgroup cols="4">
-<colspec colname="col_1" colwidth="62.5*"/>
-<colspec colname="col_2" colwidth="12.5*"/>
-<colspec colname="col_3" colwidth="12.5*"/>
-<colspec colname="col_4" colwidth="12.5*"/>
-<thead>
-<row>
-<entry align="center" valign="top">Type <literal>C</literal> Settings</entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_4">Subclassed in</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Project</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Vendor</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">World</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>C.final</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>C.ctor.accessModifier=\lenum{project}</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>C.ctor.accessModifier=\lenum{public@Internal}</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>yes</simpara></entry>
-<entry align="center" valign="top"><simpara>no</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara>Since interfaces are always to be implemented, they must not be declared final.</simpara>
-</section>
-<section xml:id="_abstract-classes">
-<title>Abstract Classes</title>
-<simpara>A class with modifier <literal>abstract</literal> is called an <emphasis>abstract class</emphasis> and has its <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math> property set to true.
-Other classes are called <emphasis>concrete</emphasis> classes.</simpara>
-<requirement xml:id="IDE-45">
-<title>Abstract Class</title>
-<simpara>
-<anchor xml:id="Req-IDE-45" xreflabel="[Req-IDE-45]"/>
-<emphasis role="strong">Requirement: IDE-45:</emphasis>
-<link linkend="Req-IDE-45">Abstract Class</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A class <literal>C</literal> must be declared abstract if it owns or inherits one or more abstract members and neither C nor any interfaces implemented by C implements these members.
-A concrete class has to, therefore, implement all abstract members of its superclasses’ implemented interfaces.
-Note that a class may implement fields with field accessors and vice versa.</simpara>
-</listitem>
-<listitem>
-<simpara>An abstract class may not be instantiated.</simpara>
-</listitem>
-<listitem>
-<simpara>An abstract class cannot be set to final (with annotation <literal>@Final</literal>).</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-46">
-<title>Abstract Member</title>
-<simpara>
-<anchor xml:id="Req-IDE-46" xreflabel="[Req-IDE-46]"/>
-<emphasis role="strong">Requirement: IDE-46:</emphasis>
-<link linkend="Req-IDE-46">Abstract Member</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<sidebar>
-<simpara><link xl:href="https://github.com/eclipse/n4js/issues/1047"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #1047</link></simpara>
-</sidebar>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A member declared as abstract must not have a method body (in contrary a method not declared as abstract have to have a method body).</simpara>
-</listitem>
-<listitem>
-<simpara>Only methods, getters and setters can be declared as abstract (fields cannot be abstract).</simpara>
-</listitem>
-<listitem>
-<simpara>It is not possible to inherit from an abstract class which contains abstract members which are not visible in the subclass.</simpara>
-</listitem>
-<listitem>
-<simpara>An abstract member must not be set to final (with annotation <literal>@Final</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>Static members must not be declared abstract.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Remarks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>We decided to disallow abstract static members, since we cannot guarantee that a static members is not accessed in all cases</simpara>
-</listitem>
-<listitem>
-<simpara>Only static members can override static members and only instance members can override other instance members of course.</simpara>
-</listitem>
-<listitem>
-<simpara>An abstract member must not be declared in a final class (i.e. a class annotated with <literal>@Final</literal>). This is not explicitly defined as constraint in <xref linkend="Req-IDE-46"/> since abstract classes must not defined final anyway. We also do not produce error message for abstract members in final classes since these errors would be consequential errors.</simpara>
-</listitem>
-</itemizedlist>
-<warning>
-<simpara>Abstract members might be declared private, as they can be accessed from within the module.
-This is to be changed in order to be aligned with TypeScript, cf. <link xl:href="https://github.com/eclipse/n4js/issues/1221"><inlinemediaobject>
-<imageobject>
-<imagedata fileref="images/issue.svg"/>
-</imageobject>
-<textobject><phrase></phrase></textobject>
-</inlinemediaobject> #1221</link>. However we also want to add class expressions — and then the abstract members may be accessed (and overridden) in nested classes created by means of class expressions.</simpara>
-</warning>
-</section>
-<section xml:id="_non-instantiable-classes">
-<title>Non-Instantiable Classes</title>
-<simpara>To make a class non-instantiable outside a defining compilation unit, i.e. disallow creation of instances for this class, simply declare the constructor as private.
-This can be used for singletons.</simpara>
-</section>
-<section xml:id="_superclass">
-<title>Superclass</title>
-<requirement xml:id="IDE-47">
-<title>Superclass</title>
-<simpara>
-<anchor xml:id="Req-IDE-47" xreflabel="[Req-IDE-47]"/>
-<emphasis role="strong">Requirement: IDE-47:</emphasis>
-<link linkend="Req-IDE-47">Superclass</link> (ver. 1)</simpara>
- <simpara>
-
-For a class <literal>C</literal> with a supertype <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo>=</mo><mi>C</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi></math>, the following constraints must hold;</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi></math> must reference a class declaration <literal>S</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>S</literal> must be be extendable in the project of <literal>C</literal></simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>∉</mo><mi>C</mi><mo>.</mo><mi>s</mi><mi>u</mi><msup><mi>p</mi><mo>+</mo></msup></math></simpara>
-</listitem>
-<listitem>
-<simpara>All abstract members in <literal>S</literal> must be accessible from <literal>C</literal>:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>M</mi><mo>∈</mo><mi>S</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi><mi>M</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi><mo>⇒</mo></math><?asciidoc-br?>
-<literal>M</literal> is accessible from <literal>C</literal>.<?asciidoc-br?>
-Note that <literal>M</literal> need not be an owned member of <literal>S</literal> and that this constraint applies even if <literal>C</literal> is abstract).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>All members of superclasses become members of a class.
-This is true even if the owning classes are not directly accessible to a class.
-The member-specific access control is not changed.</simpara>
-</requirement>
-</section>
-</section>
-<section xml:id="_interfaces" role="language-n4js">
-<title>Interfaces</title>
-<section xml:id="_definition-of-interfaces">
-<title>Definition of Interfaces</title>
-<section xml:id="interfaces-syntax">
-<title>Syntax</title>
-<formalpara>
-<title>Syntax N4 Interface Declaration</title>
-<para>
-<programlisting language="xtext" linenumbering="unnumbered">N4InterfaceDeclaration <Yield>:
- => (
- {N4InterfaceDeclaration}
- annotations+=Annotation*
- (declaredModifiers+=N4Modifier)*
- 'interface' typingStrategy=TypingStrategyDefSiteOperator? name=BindingIdentifier<Yield>?
- )
- TypeVariables?
- InterfaceImplementsList?
- Members<Yield>
-;
-
-fragment InterfaceImplementsList*:
- 'implements' superInterfaceRefs+=ParameterizedTypeRefNominal
- (',' superInterfaceRefs+=ParameterizedTypeRefNominal)*
-;</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="interfaces-properties">
-<title>Properties</title>
-<simpara>These are the additional properties of interfaces, which can be specified by the user:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>superInterfaces</literal></term>
-<listitem>
-<simpara>Collection of interfaces extended by this interface; empty by default.
-Instead of <literal>superInterfaces</literal>, we simply write <literal>interfaces</literal>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="interfaces-type-inference">
-<title>Type Inference</title>
-<simpara>The type of an interface declaration <literal>I</literal> is of type <literal>type{I}</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>I</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><mi>I</mi></mfenced></mrow></mfrac></math>
-</section>
-<section xml:id="interfaces-semantics">
-<title>Semantics</title>
-<simpara>Interfaces are used to describe the public <link linkend="_acronyms">API</link> of a classifier.
-The main requirement is that the instance of an interface, which must be an instance of a class since interfaces cannot have instances, provides all members declared in the interface.
-Thus, a (concrete) class implementing an interface must provide implementations for all the fields, methods, getters and setters of the interface (otherwise it the class must be declared abstract).
-The implementations have to be provided either directly in the class itself, through a superclass, or by the interface if the member has a default implementation.</simpara>
-<simpara>A field declaration in an interface denotes that all implementing classes can either provide a field of the same name and the same(!) type or corresponding field accessors.
-If no such members are defined in the class or a (transitive) superclass, the field is mixed in from the interface automatically.
-This is also true for the initializer of the field.</simpara>
-<simpara>All instance methods, getters and setters declared in an interface are implicitly abstract if they do not provide a default implementation.
-The modifier <literal>abstract</literal> is not required, therefore, in the source code.
-The following constraints apply:</simpara>
-<requirement xml:id="IDE-48">
-<title>Interfaces</title>
-<simpara>
-<anchor xml:id="Req-IDE-48" xreflabel="[Req-IDE-48]"/>
-<emphasis role="strong">Requirement: IDE-48:</emphasis>
-<link linkend="Req-IDE-48">Interfaces</link> (ver. 1)</simpara>
- <simpara>
-
-For any interface <literal>I</literal>, the following must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Interfaces may not be instantiated.</simpara>
-</listitem>
-<listitem>
-<simpara>Interfaces cannot be set to final (with annotation @Final): <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><mi>I</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>Members of an interface must not be declared private.
-The default access modifier in interfaces is the the type’s visibility or <literal>project</literal>, if the type’s visibility is <literal>private</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Members of an interface, except methods, must not be declared <literal>@Final</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>:</mi><mi>m</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>→</mo><mi>m</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi></math>
-<note>
-<simpara>not allowing field accessors to be declared final was a deliberate decision, because it would complicate the internal handling of member redefinition; might be reconsidered at a later time</simpara>
-</note>
-</listitem>
-<listitem>
-<simpara>The literal may not be used in the initializer expression of a field of an interface.<?asciidoc-br?>
-This restriction is required, because the order of implementation of these fields in an implementing class cannot be guaranteed.
-This applies to both instance and static fields in interfaces, but in case of static fields, <literal>this</literal> is also disallowed due to <xref linkend="_static-members-of-interfaces"/>.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>It is possible to declare members in interfaces with a smaller visibility as the interface itself.
-In that case, clients of the interface may be able to use the interface but not to implement it.</simpara>
-<simpara>In order to simplify modeling of runtime types, such as elements, interfaces do not only support the notation of static methods but constant data fields as well.
-Since <link linkend="_acronyms">IDL</link> [<link linkend="OMG14a">OMG14a</link>] is used to describe these elements in specifications (and mapped to JavaScript via rules described in [<link linkend="W3C12a">W3C12a</link>])
-constant data fields are an often-used technique there and they can be modeled in N4JS 1:1.</simpara>
-<simpara>As specified in <xref linkend="Req-IDE-56"/>, interfaces cannot contain a constructor i.e.<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mi>:</mi><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><msup><mo>≠</mo><mi>'</mi></msup><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><msup><mi>r</mi><mi>'</mi></msup></math>.</simpara>
-<example>
-<title>Simple Interfaces</title>
-<simpara>The following example shows the syntax for defining interfaces.
-The second interface extends the first one.
-Note that methods are implicitly defined abstract in interfaces.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface I {
- foo(): void
-}
-interface I2 extends I {
- someText: string;
- bar(): void
-}</programlisting>
-</example>
-<simpara>If a classifier <literal>C</literal> <emphasis>implements</emphasis> an interface <literal>I</literal>, we say <literal>I</literal> is <emphasis>implemented</emphasis> by <literal>C</literal>.
-If <literal>C</literal> redefines members declared in <literal>I</literal>, we say that these members are <emphasis>implemented</emphasis> by <literal>C</literal>.
-Members not redefined by <literal>C</literal> but with a default implementations are <emphasis>mixed in</emphasis> or <emphasis>consumed by</emphasis> <literal>C</literal>.
-We all cases we call <literal>C</literal> the <emphasis>implementor</emphasis>.</simpara>
-<simpara>Besides the general constraints described in <xref linkend="_common-semantics-of-classifiers"/>, the following constraints must hold for extending or implementing interfaces:</simpara>
-<requirement xml:id="IDE-49">
-<title>Extending Interfaces</title>
-<simpara>
-<anchor xml:id="Req-IDE-49" xreflabel="[Req-IDE-49]"/>
-<emphasis role="strong">Requirement: IDE-49:</emphasis>
-<link linkend="Req-IDE-49">Extending Interfaces</link> (ver. 1)</simpara>
- <simpara>
-
-For a given type
-<literal>I</literal>, and <math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close="}" open="{"><msub><mi>I</mi><mn>1</mn></msub><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><msub><mi>I</mi><mi>n</mi></msub></mfenced></math> directly extended by <literal>I</literal>, the following constraints must be true:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Only interfaces can extend interfaces: <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mo>,</mo><msub><mi>I</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>I</mi><mi>n</mi></msub></math> must be interfaces.</simpara>
-</listitem>
-<listitem>
-<simpara>An interface may not directly extend the same interface more than once:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>i</mi></msub><mo>=</mo><msub><mi>I</mi><mi>j</mi></msub><mo>→</mo><mi>i</mi><mo>=</mo><mi>j</mi></math> for any
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mo>,</mo><mi>j</mi><mo>∈</mo><mfenced close="}" open="{"><mrow><mn>1</mn><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mi>n</mi></mrow></mfenced></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>An interface may (indirectly) extend the same interface <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> more than once only if</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> is not parameterized, or</simpara>
-</listitem>
-<listitem>
-<simpara>in all cases <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> is extended with the same type arguments for all invariant type parameters.<?asciidoc-br?>
-Note that for type parameters of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> that are declared covariant or contravariant on definition site, different type arguments may be used.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>All abstract members in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>i</mi></msub></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mo>∈</mo><mfenced close="}" open="{"><mn>1</mn><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mi>n</mi></mfenced></math>, must be accessible from <literal>I</literal>:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>i</mi><mo>∈</mo><mfenced close="}" open="{"><mn>1</mn><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mi>n</mi></mfenced><mi>:</mi><mi>M</mi><mo>∈</mo><msub><mi>I</mi><mi>i</mi></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>∧</mo><mi>M</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi><mo>→</mo></math> <literal>M</literal> is accessible from <literal>I</literal>.<?asciidoc-br?>
-Note that <literal>M</literal> need not be an owned member of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>i</mi></msub></math>.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-50">
-<title>Implementing Interfaces</title>
-<simpara>
-<anchor xml:id="Req-IDE-50" xreflabel="[Req-IDE-50]"/>
-<emphasis role="strong">Requirement: IDE-50:</emphasis>
-<link linkend="Req-IDE-50">Implementing Interfaces</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For a given type
-<literal>C</literal>, and <math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close="}" open="{"><msub><mi>I</mi><mn>1</mn></msub><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><msub><mi>I</mi><mi>n</mi></msub></mfenced></math> directly implemented
-by <literal>C</literal>, the following constraints must be true:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Only classes can implement interfaces: <literal>C</literal> must be a Class.</simpara>
-</listitem>
-<listitem>
-<simpara>A class can only implement interfaces: <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>I</mi><mi>n</mi></msub></math> must be interfaces.</simpara>
-</listitem>
-<listitem>
-<simpara>A class may not directly implement the same interface more than once:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>i</mi></msub><mo>=</mo><msub><mi>I</mi><mi>j</mi></msub><mo>⇒</mo><mi>i</mi><mo>=</mo><mi>j</mi></math> for any <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mo>,</mo><mi>j</mi><mo>∈</mo><mfenced close="}" open="{"><mn>1</mn><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mi>n</mi></mfenced></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>A class may (indirectly) implement the same interface <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> more than once only if</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> is not parameterized, or</simpara>
-</listitem>
-<listitem>
-<simpara>in all cases <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> is implemented with the same type arguments for all invariant type parameters.<?asciidoc-br?>
-Note that for type parameters of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>J</mi></math> that are declared covariant or contravariant on definition site, different type arguments may be used.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>All abstract members in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>i</mi></msub></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mo>∈</mo><mfenced close="}" open="{"><mn>1</mn><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mi>n</mi></mfenced></math>, must be accessible from <literal>C</literal>:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>i</mi><mo>∈</mo><mfenced close="}" open="{"><mn>1</mn><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mi>n</mi></mfenced><mi>:</mi><mi>M</mi><mo>∈</mo><msub><mi>I</mi><mi>i</mi></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>∧</mo><mi>M</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi><mo>→</mo></math> <literal>M</literal> is accessible from <literal>C</literal>.<?asciidoc-br?>
-Note that <literal>M</literal> need not be an owned member of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>i</mi></msub></math>.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>For default methods in interfaces, see <xref linkend="_default-methods-in-interfaces"/>.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_generic-classifiers" role="language-n4js">
-<title>Generic Classifiers</title>
-<simpara>Classifiers can be declared generic by defining a type parameter via <literal>type-param</literal>.</simpara>
-<definition>
-<title>Generic Classifiers</title>
-<simpara>
-<anchor xml:id="generic_classifiers" xreflabel="[generic_classifiers]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="generic_classifiers">Generic Classifiers</link></simpara>
-<simpara>
-
-A generic classifier is a classifier with at least one type parameter.
-That is, a given classifier <literal>C</literal> is generic if and only if <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>C</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>≥</mo><mn>1</mn></math>.</simpara>
-<simpara>If a classifier does not define any type parameters, it is not generic, even if its superclass or any implemented interface is generic.</simpara>
-<simpara>The format of the type parameter expression is described in <xref linkend="_parameterized-types"/>.
-The type variable defined by the type parameter’s type expression can be used just like a normal type inside the class definition.</simpara>
-<simpara>If using a generic classifier as type of a variable, it may be parameterized.
-This is usually done via a type expression (cf. <xref linkend="_parameterized-types"/>) or via <literal>typearg</literal> in case of supertypes.
-If a generic classifier defines multiple type variables, these variables are bound in the order of their definition.
-In any case, all type variables have to be bound.
-That means in particular that raw types are not allowed. (cf <xref linkend="_parameterized-types"/> for details).</simpara>
-<simpara>If a generic classifier is used as super classifier, the type arguments can be type variables.
-Note that the type variable of the super classifier is not lifted, that is to say that all type variables are to be explicitly bound in the type references used in the <literal>extend</literal>, <literal>with</literal>, or <literal>implements</literal> section using <literal>typearg</literal>.
-If a type variable is used in <literal>typearg</literal> to bound a type variable of a type parameter, it has to fulfil possible type constraints (upper/lower bound) specified in the type parameter.</simpara>
-</definition>
-<example>
-<title>Generic Type Definition and Usage as Type of Variable</title>
-<simpara>This example demonstrates how to define a generic type and how to refer to it in a variable definition.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">export class Container<T> {
- private item: T;
-
- getItem(): T {
- return this.item;
- }
-
- setItem(item: T): void {
- this.item = item;
- }
-}</programlisting>
-</example>
-<simpara>This type can now be used as a type of a variable as follows</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import Container from "p/Container"
-
-var stringContainer: Container<string> = new Container<string>();
-stringContainer.setItem("Hello");
-var s: string = stringContainer.getItem();</programlisting>
-<simpara>In line 3, the type variable <literal>T</literal> of the generic class <literal>Container</literal> is bound to <literal>string</literal>.</simpara>
-<example>
-<title>Binding of type variables with multiple types</title>
-<simpara>For a given generic class <literal>G</literal></simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A{}
-class B{}
-class C extends A{}
-
-class G<S, T extends A, U extends B> {
-}</programlisting>
-<simpara>the variable definition</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var x: G<Number,C,B>;</programlisting>
-<simpara>would bind the type variables as follows:</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="16.6666*"/>
-<colspec colname="col_2" colwidth="16.6666*"/>
-<colspec colname="col_3" colwidth="66.6668*"/>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><literal>S</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>Number</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>Bound by first type argument, no bound constraints defined for <literal>S</literal>.</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>T</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>C</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>Bound by second type argument, <literal>C</literal> must be a subtype of in order to fulfill the type constraint.</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>U</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>B</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>Bound by third type argument, <literal>extends</literal> is reflexive, that is <literal>B</literal> fulfills the
-type constraint.</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</example>
-<requirement xml:id="IDE-51">
-<title>Generic Superclass, Type Argument with Type Variable</title>
-<simpara>
-<anchor xml:id="Req-IDE-51" xreflabel="[Req-IDE-51]"/>
-<emphasis role="strong">Requirement: IDE-51:</emphasis>
-<link linkend="Req-IDE-51">Generic Superclass, Type Argument with Type Variable</link> (ver. 1)</simpara>
- <simpara>
-
-For a given generic superclass <literal>SuperClass</literal></simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class SuperClass<S, T extends A, U extends B> {};</programlisting>
-<simpara>and a generic subclass <literal>SubClass</literal></simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class SubClass<X extends A> extends SuperClass<Number, X, B> {..};</programlisting>
-<simpara>the variable definition</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var s: SubClass<C>;</programlisting>
-<simpara>would bind the type variables as follows:<?asciidoc-br?></simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="16.6666*"/>
-<colspec colname="col_2" colwidth="16.6666*"/>
-<colspec colname="col_3" colwidth="66.6668*"/>
-<thead>
-<row>
-<entry align="center" valign="top">TypeVariable</entry>
-<entry align="center" valign="top">Bound to</entry>
-<entry align="center" valign="top">Explanation</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><literal>SuperClass.S</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>Number</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>Type variable <literal>s</literal> of supertype <literal>SuperClass</literal> is bound to <literal>Number</literal>.</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>SuperClass.T</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>SubClass.X=C</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>Type variable <literal>T</literal> of supertype <literal>SuperClass</literal> is bound to type variable <literal>X</literal> of <literal>SubClass</literal>. It gets
-then indirectly bound to <literal>C</literal> as specified by the type argument of the
-variable definition.</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>SuperClass.U</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>B</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>Type variable <literal>U</literal> of supertype <literal>SuperClass</literal> is auto-bound to <literal>C</literal> as no explicit binding for the third type variable is specified.</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>SubClass.X</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>C</literal></simpara></entry>
-<entry align="left" valign="top"><simpara>Bound by first type argument specified in variable definition.</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</requirement>
-</section>
-<section xml:id="sec:definition-site-variance" role="language-n4js">
-<title>Definition-Site Variance</title>
-<simpara>In addition to use-site declaration of variance in the form of Java-like wildcards, N4JS provides support for definition-site declaration of variance as known from languages such as C# and Scala.</simpara>
-<simpara>The <emphasis>variance</emphasis> of a parameterized type states how its subtyping relates to its type arguments’ subtyping.
-For example, given a parameterized type <literal>G<T></literal> and plain types <literal>A</literal> and <literal>B</literal>, we know</simpara>
-<itemizedlist>
-<listitem>
-<simpara>if <literal>G</literal> is <emphasis role="strong">covariant</emphasis> w.r.t. its parameter <literal>T</literal>, then</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>A</mtext></mstyle><mo>→</mo><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mo>></mo><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>A</mtext></mstyle><mo>></mo></math></simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>G</literal> is <emphasis role="strong">contravariant</emphasis> w.r.t. its parameter <literal>T</literal>, then</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>A</mtext></mstyle><mo>→</mo><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>A</mtext></mstyle><mo>></mo><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mo>></mo></math></simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>G</literal> is <emphasis role="strong">invariant</emphasis> w.r.t. its parameter <literal>T</literal>, then</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>A</mtext></mstyle><mo>→</mo><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>A</mtext></mstyle><mo>></mo><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mo>></mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>A</mtext></mstyle><mo>→</mo><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>A</mtext></mstyle><mo>></mo><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>G</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mo>></mo></math></simpara>
-</listitem>
-</itemizedlist>
-<simpara>Note that variance is declared per type parameter, so a single parameterized type with more than one type parameter may be, for example, covariant w.r.t. one type parameter and contravariant w.r.t. another.</simpara>
-<simpara>Strictly speaking, a type parameter/variable itself is not co- or contravariant;<?asciidoc-br?>
-however, for the sake of simplicity we say <emphasis><literal>T</literal> is covariant</emphasis> as a short form for <emphasis><literal>G</literal> is covariant with respect to its type parameter <literal>T</literal></emphasis> (for contravariant and invariant accordingly).</simpara>
-<simpara>To declare the variance of a parameterized classifier on definition site, simply add keyword <literal>in</literal> or <literal>out</literal> before the corresponding type parameter:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class ReadOnlyList<out T> { // covariance
- // ...
-}
-
-interface Consumer<in T> { // contravariance
- // ...
-}</programlisting>
-<simpara>In such cases, the following constraints apply.</simpara>
-<requirement xml:id="IDE-174">
-<title>Definition-Site Variance</title>
-<simpara>
-<anchor xml:id="Req-IDE-174" xreflabel="[Req-IDE-174]"/>
-<emphasis role="strong">Requirement: IDE-174:</emphasis>
-<link linkend="Req-IDE-174">Definition-Site Variance</link> (ver. 1)</simpara>
- <simpara>
-
-Given a parameterized type with a type parameter , the following must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>T</literal> may only appear in variance-compatible positions:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>if <literal>T</literal> is declared on definition site to be <emphasis role="strong">covariant</emphasis>, then it may only appear in covariant positions within the type’s non-private member declarations.</simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>T</literal> is declared on definition site to be <emphasis role="strong">contravariant</emphasis>, then it may only appear in contravariant positions within the type’s non-private member declarations.</simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>T</literal> is <emphasis role="strong">invariant</emphasis>, i.e. neither declared covariant nor declared contravariant on definition site, then it may appear in any position (where type variables are allowed).</simpara>
-<simpara>Thus, no restrictions apply within the declaration of private members and within the body of field accessors and methods.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>definition-site variance may not be combined with incompatible use-site variance:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>if <literal>T</literal> is declared on definition site to be <emphasis role="strong">covariant</emphasis>, then no wildcard with a <emphasis role="strong">lower</emphasis> bound may be provided as type argument for <literal>T</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>T</literal> is declared on definition site to be <emphasis role="strong">contravariant</emphasis>, then no wildcard with an <emphasis role="strong">upper</emphasis> bound may be provided as type argument for <literal>T</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>T</literal> is <emphasis role="strong">invariant</emphasis>, i.e. neither declared covariant nor declared contravariant on definition site, then any kind of wildcard may be provided as type argument.</simpara>
-<simpara>Unbounded wildcards are allowed in all cases.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</requirement>
-<example xml:id="ex:use-site-declaration-variance">
-<title>Use-site declaration of variance</title>
-<simpara>For illustration purposes, let’s compare use-site and definition-site declaration of variance.
-Since use-site variance is more familiar to the Java developer, we start with this flavor.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class Person {
- name: string;
-}
-class Employee extends Person {}
-
-interface List<T> {
- add(elem: T)
- read(idx: int): T
-}
-
-function getNameOfFirstPerson(list: List<? extends Person>): string {
- return list.read(0).name;
-}</programlisting>
-<simpara>Function <literal>getNameOfFirstPerson</literal> below takes a list and returns the name of the first person in the list.
-Since it never adds new elements to the given list, it could accept <literal>List</literal>s of any subtype of <literal>Person</literal>, for example a <literal>List<Employee></literal>.
-To allow this, its formal parameter has a type of <literal>List<? extends Person></literal> instead of <literal>List<Person></literal>.
-Such use-site variance is useful whenever an invariant type, like <literal>List</literal> above, is being used in a way such that it can be treated as if it were co- or contravariant.</simpara>
-<simpara>Sometimes, however, we are dealing with types that are inherently covariant or contravariant, for example an <literal>ImmutableList</literal> from which we can only read elements would be covariant.
-In such a case, use-site declaration of variance is tedious and error-prone: we would have to declare the variance wherever the type is being used and would have to
-make sure not to forget the declaration or otherwise limit the flexibility and reusability of the code (for example, in the above code we could not call <literal>getNameOfFirstPerson</literal> with a <literal>List<Employee></literal>).</simpara>
-<simpara>The solution is to declare the variance on declaration site, as in the following code sample:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface ImmutableList<out T> {
-// add(elem: T) // error: such a method would now be disallowed
- read(idx: int): T
-}
-
-function getNameOfFirstPerson2(list: ImmutableList<Person>): string {
- return list.read(0).name;
-}</programlisting>
-<simpara>Now we can invoke <literal>getNameOfFirstPerson2</literal> with a <literal>List<Employee></literal> even though the implementor of <literal>getNameOfFirstPerson2</literal> did not add a
-use-site declaration of covariance, because the type <literal>ImmutableList</literal> is declared to be covariant with respect to its parameter <literal>T</literal>, and this applies globally
-throughout the program.</simpara>
-</example>
-</section>
-</section>
-<section xml:id="_members">
-<title>Members</title>
-<simpara>A member is either a method (which may be a special constructor function), a data field, or a getter or a setter.
-The latter two implicitly define an accessor field.
-Similar to object literals, there must be no data field with the same name as a getter or setter.</simpara>
-<simpara>(overriding, implementation and consumption) is
-described in <xref linkend="_redefinition-of-members"/>.</simpara>
-<section xml:id="_syntax-4" role="language-n4js">
-<title>Syntax</title>
-<formalpara>
-<title>Syntax N4JS member access modifier</title>
-<para>
-<programlisting language="xtext" linenumbering="unnumbered">enum N4JSMemberAccessModifier: private | project | protected | public;
-
-N4MemberDeclaration: N4MethodDeclaration | N4FieldDeclaration | N4GetterDeclaration | N4SetterDeclaration;</programlisting>
-</para>
-</formalpara>
-<section xml:id="_properties-3">
-<title>Properties</title>
-<simpara>Members share the following properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>annotations</literal> </term>
-<listitem>
-<simpara>Arbitrary annotations, see <xref linkend="_annotations"/> for details.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>accessModifier</literal> </term>
-<listitem>
-<simpara>N4JS member access modifier: <literal>private</literal>, <literal>project</literal>, <literal>potected</literal>, or <literal>public</literal>; the latter two can be combined with <literal>@Internal</literal>; default is <literal>project</literal> for classes and private interfaces.
-For a non-private interface defaults to the interface’s visibility.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>name</literal> </term>
-<listitem>
-<simpara>The simple name of the member, that is an identifier name (cf. <xref linkend="_valid-names"/>).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>static</literal> </term>
-<listitem>
-<simpara>Boolean property to distinguish instance from classifier members, see <xref linkend="_static-members"/>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The following pseudo properties are defined via annotations:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>deprecated</literal> </term>
-<listitem>
-<simpara>Boolean property set to true if annotation <literal>@Deprecated</literal> is set. <footnote><simpara>not yet implemented</simpara></footnote></simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>And we additionally define the following pseudo properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>acc</literal> </term>
-<listitem>
-<simpara>Member access modifier as described in <xref linkend="_accessibility-of-members"/>, it is the aggregated value of
-the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi></math> and the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>x</mi><mi>p</mi><mi>o</mi><mi>r</mi><mi>t</mi></math> property.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>owner</literal> </term>
-<listitem>
-<simpara>Owner classifier of the member.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>typeRef</literal> </term>
-<listitem>
-<simpara>Type of the member—this is the type of a field or the type of the method which is a function type (and not the return type).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>assignability</literal> </term>
-<listitem>
-<simpara>Enumeration, may be one of the following values:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>set</literal></term>
-<listitem>
-<simpara>Member may only be set, i.e. it could only be used on the left hand side of an assignment.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>get</literal></term>
-<listitem>
-<simpara>Member may only be retrieved, i.e. it could only be used on the right hand side of an assignment. This is the default setting for methods.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>any</literal></term>
-<listitem>
-<simpara> Member may be set or retrieved, i.e. it could only be used on the left or right hand side of an assignment.
-This is the default setting for fields.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</varlistentry>
-</variablelist>
-<note>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi></math> is related but not equal to writable modifiers used for fields.
-We define a partial order on this enumeration as follows:<?asciidoc-br?></simpara>
-</note>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo><</mo><mfenced close=")" open="("><mi>l</mi><mi>r</mi></mfenced><mspace width="3.0mm"/><mi>:</mi><mi>:</mi><mo>=</mo><mspace width="3.0mm"/><mfenced close="}" open="{"><mfenced close=")" open="("><mstyle mathvariant="monospace"><mtext>set</mtext></mstyle><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mfenced><mfenced close=")" open="("><mstyle mathvariant="monospace"><mtext>get</mtext></mstyle><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mfenced></mfenced></math>
-<variablelist>
-<varlistentry>
-<term><literal>abstract</literal> </term>
-<listitem>
-<simpara>All members have a flag <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math>, which is user-defined for methods, getters and setter, but which is always false for fields.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The following pseudo property is set to make fields compatible with properties of an object literal, however it cannot be changed:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>configurable</literal> </term>
-<listitem>
-<simpara>Boolean flag reflecting the property descriptor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>o</mi><mi>n</mi><mi>f</mi><mi>i</mi><mi>g</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math>, this is always set to false for members.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-</section>
-<section xml:id="_semantics-3">
-<title>Semantics</title>
-<simpara>The members of a given classifier <literal>C</literal> must be named such that the following constraints are met:</simpara>
-<requirement xml:id="IDE-52">
-<title>Member Names</title>
-<simpara>
-<anchor xml:id="Req-IDE-52" xreflabel="[Req-IDE-52]"/>
-<emphasis role="strong">Requirement: IDE-52:</emphasis>
-<link linkend="Req-IDE-52">Member Names</link> (ver. 1)</simpara>
- <simpara>
-
-. The name of a member is given as an identifier, a string literal, a numeric literal, or as a computed property name with a compile-time expression (see <xref linkend="compile-time-expressions"/>). In particular, string literals, e.g. <literal>['myProp']</literal>, built-in symbols, e.g. <literal>[Symbol.iterator]</literal>, and literals of <literal>@StringBased</literal> enums are all valid computed property names.
-. No two members may have the same name, except one is static and the
-other is non-static:</simpara>
-<simpara>+</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mo>∀</mo><msub><mi>m</mi><mn>1</mn></msub><mo>,</mo><msub><mi>m</mi><mn>2</mn></msub><mo>∈</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><msub><mi>m</mi><mn>1</mn></msub><mo>≠</mo><msub><mi>m</mi><mn>2</mn></msub><mi>:</mi><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>≠</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>∨</mo><msub><mi>m</mi><mn>1</mn></msub><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>≠</mo><msub><mi>m</mi><mn>2</mn></msub><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></mtd></mtr></mtable></math>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The member name must be a valid identifier name, see <link linkend="_identifier-names-and-identifiers">Identifier Grammar</link>.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Thus, over<emphasis>loading</emphasis> of methods is not supported <footnote><simpara>In order to emulate method overloading, union types are to be used.</simpara></footnote> and no field may have the same name as a method.
-However, over<emphasis>riding</emphasis> of methods, getters, and setters are possible, see <xref linkend="_redefinition-of-members"/>.
-Static members may also have the same name as non-static members.<footnote><simpara>[<link linkend="ECMA15a">ECMA15a(p.p214)</link>], <literal>ClassBody : ClassElementList</literal> indicates that it is possible to have the same name for instance and static members.</simpara></footnote></simpara>
-<simpara>The dollar character <literal>$</literal> is not allowed for user-defined member identifiers as the dollar sign is used for rewriting private members.</simpara>
-</section>
-<section xml:id="_methods" role="language-n4js">
-<title>Methods</title>
-<simpara>Methods are simply JavaScript functions.
-They are defined similarly to methods as proposed in [<link linkend="ECMA15a">ECMA15a(p.S13.5)</link>] except for the type information and some modifiers.</simpara>
-<section xml:id="_syntax-5">
-<title>Syntax</title>
-<formalpara>
-<title>Syntax Method Declaration</title>
-<para>
-<programlisting language="xtext" linenumbering="unnumbered">N4MethodDeclaration <Yield>:
- => ({N4MethodDeclaration}
- annotations+=Annotation*
- accessModifier=N4JSMemberAccessModifier?
- (abstract?=’abstract’ | static?=’static’)?
- TypeVariables?
- (
- generator?='*' LiteralOrComputedPropertyName<Yield> -> MethodParamsReturnAndBody <Generator=true>
- | AsyncNoTrailingLineBreak LiteralOrComputedPropertyName<Yield> -> MethodParamsReturnAndBody <Generator=false>
- )
- ) ';'?
-;
-
-fragment MethodParamsAndBody <Generator>*:
- StrictFormalParameters<Yield=Generator>
- (body=Block<Yield=Generator>)?
-;
-
-fragment MethodParamsReturnAndBody <Generator>*:
- StrictFormalParameters<Yield=Generator>
- (':' returnTypeRef=TypeRef)?
- (body=Block<Yield=Generator>)?
-;
-
-fragment LiteralOrComputedPropertyName <Yield>*:
- name=IdentifierName | name=STRING | name=NumericLiteralAsString
- | '[' (=>((name=SymbolLiteralComputedName<Yield> | name=StringLiteralAsName) ']') | computeNameFrom=AssignmentExpression<In=true,Yield> ']')
-;
-
-SymbolLiteralComputedName <Yield>:
- BindingIdentifier<Yield> ('.' IdentifierName)?
-;
-
-BindingIdentifier <Yield>:
- IDENTIFIER
- | <!Yield> 'yield'
- | N4Keyword
-;
-
-IdentifierName: IDENTIFIER | ReservedWord | N4Keyword;
-NumericLiteralAsString: DOUBLE | INT | OCTAL_INT | HEX_INT | SCIENTIFIC_INT;
-StringLiteralAsName: STRING;
-
-fragment AsyncNoTrailingLineBreak *: (declaredAsync?='async' NoLineTerminator)?; // See Asynchronous Functions
-
-fragment StrictFormalParameters <Yield>*:
- '(' (fpars+=FormalParameter<Yield> (',' fpars+=FormalParameter<Yield>)*)? ')'
-;
-
-FormalParameter <Yield>:
- {FormalParameter} BindingElementFragment<Yield>
-;
-
-fragment BindingElementFragment <Yield>*:
- (=> bindingPattern=BindingPattern<Yield>
- | annotations+=Annotation*
- (
- variadic?='...'? name=BindingIdentifier<Yield> ColonSepTypeRef?
- )
- )
- ('=' initializer=AssignmentExpression<In=true, Yield>)?
-;
-
-fragment ColonSepTypeRef*:
- ':' declaredTypeRef=TypeRef
-;</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="_properties-4" role="language-n4js">
-<title>Properties</title>
-<simpara>Methods have all the properties of members and the following additional properties can be explicitly defined:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>abstract</literal> </term>
-<listitem>
-<simpara>Method is declared but not defined.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>typePars</literal> </term>
-<listitem>
-<simpara>Collection of type parameters of a generic method; empty by default.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>returnTypeRef</literal> </term>
-<listitem>
-<simpara>Return type of the method, default return type is <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="italic"><mi>V</mi><mi>o</mi><mi>i</mi><mi>d</mi></mstyle></math>.
-The type of the method as a member of the owning classifier is not the method’s return type but is instead a function type.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fpars</literal> </term>
-<listitem>
-<simpara>List of formal parameters, may be left empty.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>body</literal> </term>
-<listitem>
-<simpara>The body of the method (this is not available in the pure types model)</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The following pseudo properties are defined via annotations:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>final</literal> </term>
-<listitem>
-<simpara>Boolean flag set to true if annotation <literal>@Final</literal> is set.
-The flag indicates that method must not be overridden in subclasses; see <xref linkend="_final-methods"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>declaresOverride</literal> </term>
-<listitem>
-<simpara>Flag set to true if annotation <literal>@Overrides</literal> is set. The flag indicates that method must override a method of a superclass; see <xref linkend="_overriding-of-members"/>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Additionally, we define the following pseudo properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>overrides</literal> </term>
-<listitem>
-<simpara>True if method overrides a super method or implements an interface method, false otherwise.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>typeRef</literal> </term>
-<listitem>
-<simpara>Type of the method. This is, in fact, a function type (and not the return type).</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The following pseudo property is set to make methods compatible with properties of an object literal, however it cannot be changed:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>enumerable</literal> </term>
-<listitem>
-<simpara>Boolean flag reflecting the property descriptor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>n</mi><mi>u</mi><mi>m</mi><mi>e</mi><mi>r</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math>, this is always set to false for methods.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_semantics-4">
-<title>Semantics</title>
-<simpara>Since methods are ECMAScript functions, all constraints specified in <xref linkend="_function-type"/> apply to methods as well.
-This section describes default values and function type conformance which is required for overriding and implementing methods.</simpara>
-<simpara>In addition, method declarations and definitions have to comply with the constraints for naming members of classifiers (cf. <xref linkend="Req-IDE-52"/>)
-and with the constraints detailed in the following sections on final methods (<xref linkend="_final-methods"/>), abstract methods (<xref linkend="_abstract-methods"/> and
-method overriding and implementation (<xref linkend="_overriding-of-members"/>, <xref linkend="_implementation-of-members"/>).</simpara>
-<simpara>The following constraints are defined for methods in ECMAScript 6 [<link linkend="ECMA15a">ECMA15a(p.207)</link>]</simpara>
-<requirement xml:id="IDE-53">
-<title>Method Definition ECMAScript 6</title>
-<simpara>
-<anchor xml:id="Req-IDE-53" xreflabel="[Req-IDE-53]"/>
-<emphasis role="strong">Requirement: IDE-53:</emphasis>
-<link linkend="Req-IDE-53">Method Definition ECMAScript 6</link> (ver. 1)</simpara>
- <simpara>
-
-* It is a Syntax Error if any element of the BoundNames of StrictFormalParameters also occurs in the VarDeclaredNames of FunctionBody.
-* It is a Syntax Error if any element of the BoundNames of StrictFormalParameters also occurs in the LexicallyDeclaredNames of FunctionBody.</simpara>
-</requirement>
-<simpara>Methods – like functions – define a variable execution environment and therefore provide access to the actual passed-in parameters through the implicit <literal>arguments</literal> variable inside of their bodies (c.f. <xref linkend="_arguments-object"/>).</simpara>
-<simpara>Methods are similar to function definitions but they must not be assigned to or from variables.
-The following code issues an error although the type of the method would be compatible to the type of the variable <literal>v</literal>:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- m(): void {}
-}
-var v: {function():void} = new C().m;</programlisting>
-<requirement xml:id="IDE-54">
-<title>Method Assignment</title>
-<simpara>
-<anchor xml:id="Req-IDE-54" xreflabel="[Req-IDE-54]"/>
-<emphasis role="strong">Requirement: IDE-54:</emphasis>
-<link linkend="Req-IDE-54">Method Assignment</link> (ver. 1)</simpara>
- <simpara>
-
-. In contrast to ECMAScript 2015, methods are defined as readonly, that is, it is not possible to dynamically re-assign a property defined as method with a new value.
-This is because assigning or re-assigning a method breaks encapsulation. Methods are the <xref linkend="_acronyms"/> of a class, their implementation is internal to the class.
-. When assigning a method to a variable, a warning is issued since this would lead to an detached this reference inside the method when it is called without explicitly providing the receiver. No warning is issued only if it is guaranteed that no problems will occur:
-.. The method’s body can be determined at compile time (i.e., it has been declared <literal>@Final</literal>) and it lacks usages of <literal>this</literal> or <literal>super</literal>. This is true for instance and static methods.
-.. The method is the constructor.</simpara>
-</requirement>
-<note>
-<simpara>The following code demonstrates problems arising when methods are assigned to variables in terms of function expressions.
-Given are two classes and instances of each class as follows:</simpara>
-</note>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- m(): void { }
- static k(): void {}
-}
-class D extends C {
- @Override m(): void { this.f()}
- f(): void {}
-
- @Override static k(): void { this.f()}
- static f(): void {}
-}
-var c: C = new C();
-var d: C = new D(); // d looks like a C</programlisting>
-<simpara>Assigning an instance method to a variable could cause problems, as the method assumes this to be bound to the class in which it is defined.
-This may work in some cases, but will cause problems in particular in combination with method overriding:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var v1: {@This(C)function():void} = c.m;
-var v2: {@This(C)function():void} = d.m;
-
-v1.call(c);
-v2.call(c);</programlisting>
-<simpara>Calling <literal>c.m</literal> indirectly via <literal>v1</literal> with <literal>c</literal> as this object will work.
-However, it won’t work for <literal>v2</literal>: the method is overridden in <literal>D</literal>, and the method in expects other methods available in <literal>D</literal> but not in <literal>C</literal>.
-That is, the last call would lead to a runtime error as method <literal>f</literal> which is called in <literal>D.m</literal> won’t be available.</simpara>
-<simpara>The same scenario occurs in case of static methods if they are retrieved polymorphically via the variables of type <literal>constructor{C}</literal>:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var ctor: constructor{C} = C;
-var dtor: constructor{C} = D;
-
-var v3: {@This(constructor{C})function():void} = ctor.k;
-var v4: {@This(constructor{C})function():void} = dtor.k;</programlisting>
-<simpara>In both cases, the problem could be solved by restricting these kinds of assignments to final methods only.
-In the static case, the problem would also be solved by accessing the static method directly via the class type (and not polymorphically via the constructor).
-Both restrictions are severe but would be necessary to avoid unexpected runtime problems.</simpara>
-<simpara>The following example shows a problem with breaking the encapsulation of a class.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- x: any = "";
- f(): void { this.g(this); }
- g(c: C): void { c.h(); }
- h(): void {}
-}
-class D extends C {
-
- @Override f(): void {
- this.g(this.x);
- }
- @Override g(c: any) {
- // do nothing, do not call h())
- }
-}
-
-var c = new C();
-var d = new D();
-
-var v5: {@This(C)function():void} = c.f;
-var v6: {@This(C)function():void} = d.f;
-
-v5.call(c)
-v6.call(c)</programlisting>
-<simpara>In <literal>D</literal>, method <literal>g</literal> is overridden to accept more types as the original method defined in <literal>C</literal>.
-Calling this new method with receiver type <literal>C</literal> (as done in the last line) will cause problems, as in <literal>D</literal> not only <literal>f</literal> has been adapted but also <literal>g</literal>.
-Eventually, this would lead to a runtime error as well.</simpara>
-</section>
-<section xml:id="_final-methods">
-<title>Final Methods</title>
-<simpara>By default, methods can be overridden.
-To prevent a method from being overridden, it must be annotated with <literal>@Final</literal>.</simpara>
-<simpara>Of course, a method cannot be declared both abstract and final (cf. <xref linkend="Req-IDE-46"/>).
-Private methods are implicitly declared final.
-Because static methods can be overridden in subclasses (which is different to Java), they also can be marked as final.</simpara>
-<simpara>Default methods in interfaces, cf. <xref linkend="_default-methods-in-interfaces"/>, may also be declared <literal>@Final</literal>.</simpara>
-<example>
-<title>Final Methods in Interfaces</title>
-<simpara>If a method in an interface is provided with a body, it may be declared final.
-This will ensure that the given method’s body will be in effect for all instances of the interface.
-Note that this means that;</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>a class implementing that interface must not define a method with the same name and</simpara>
-</listitem>
-<listitem>
-<simpara>a class inheriting a method of that name cannot implement this interface.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The latter case is illustrated here:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface I {
- @Final m(): void {}
-}
-
-class C1 {
- m(): void {}
-}
-
-// error at "I": "The method C1.m cannot override final method I.m."
-class C2 extends C1 implements I {
-}</programlisting>
-</example>
-</section>
-<section xml:id="_abstract-methods">
-<title>Abstract Methods</title>
-<simpara>A method can be declared without defining it, i.e. without providing a method body, and is then called an <emphasis>abstract method</emphasis>.
-Such methods must be declared with modifier <literal>abstract</literal> and have their property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math> set to true.
-Constraints for abstract methods are covered in <xref linkend="Req-IDE-46"/> (see <xref linkend="_abstract-classes"/>).</simpara>
-<simpara>In interfaces, methods are always abstract by default and they do not have to be marked as abstract.
-If a method in an interface provides a body, then this is the default implementation.
-See <xref linkend="_implementation-of-members"/> about how the default implementation may be mixed in the consumer.</simpara>
-</section>
-<section xml:id="_generic-methods" role="language-n4js">
-<title>Generic Methods</title>
-<simpara>Methods of generic classes can, of course, refer to the type variables defined by type parameters of the generic class.
-These type variables are used similarly to predefined or declared types.
-Additionally, methods may be declared generic independently from their containing class.
-That is to say that type parameters (with type variables) can be defined for methods as well, just like for generic functions (see <xref linkend="_generic-functions"/>).</simpara>
-<requirement xml:id="IDE-55">
-<title>Type variable names for generic methods</title>
-<simpara>
-<anchor xml:id="Req-IDE-55" xreflabel="[Req-IDE-55]"/>
-<emphasis role="strong">Requirement: IDE-55:</emphasis>
-<link linkend="Req-IDE-55">Type variable names for generic methods</link> (ver. 1)</simpara>
- <simpara>
-
-For a given generic method <literal>M</literal> of a class <literal>C</literal>, the following
-constraint must hold:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi> </mi><mi>t</mi><msub><mi>p</mi><mi>m</mi></msub><mo>∈</mo><mi>m</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>t</mi><msub><mi>p</mi><mi>C</mi></msub><mo>∈</mo><mi>C</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mi>:</mi><mi>t</mi><msub><mi>p</mi><mi>m</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>≠</mo><mi>t</mi><msub><mi>p</mi><mi>C</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math></simpara>
-</requirement>
-<simpara>Since type variables can be used similarly to types in the scope of a generic class, a generic method may refer to a type variable of its containing class.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- <T> foo(p: T p): T { return p;}
-};</programlisting>
-<simpara>If a generic type parameter is not used as a formal parameter type or the return type, a warning is generated unless the method overrides a member inherited from a super class or interface.</simpara>
-</section>
-</section>
-<section xml:id="_default-methods-in-interfaces">
-<title>Default Methods in Interfaces</title>
-<simpara>If a method declared in an interface defines a body, then this is the so-called <emphasis>default implementation</emphasis> and the method is called a <emphasis>default method</emphasis>.
-This will be mixed into an implementor of the interface if, and only if, neither the implementing class nor any of its direct or indirect superclasses already provides an implementation for this method;
-for details see <xref linkend="_member-consumption"/>.
-Since the implementor is not known, some constraints exist for the body. I.e., no access to super is possible, cf. <xref linkend="Req-IDE-124"/>.</simpara>
-<simpara>In order to declare an interface to provide a default implementation in a definition file, annotation <literal>@ProvidesDefaultImplementation</literal> can be used, cf. <xref linkend="Req-IDE-167"/>.</simpara>
-<simpara>When a method in an interface is provided with a default implementation, it may even be declared <literal>@Final</literal>, see <xref linkend="_final-methods"/>.</simpara>
-<section xml:id="_asynchronous-methods">
-<title>Asynchronous Methods</title>
-<simpara>N4JS implements the async/await concept proposed for ECMAScript 7, which provides a more convenient and readable syntax for writing asynchronous code compared to using built-in type Promise directly.
-This concept can be applied to methods in exactly the same way as to declared functions.
-See <xref linkend="_asynchronous-functions"/> and <xref linkend="_asynchronous-arrow-functions"/> for details.</simpara>
-</section>
-</section>
-<section xml:id="_constructors" role="language-n4js">
-<title>Constructors</title>
-<simpara>A constructor is a special function defined on a class which returns an instance of that class.
-The constructor looks like a normal method with name "constructor".
-The constructor can be defined explicitly or implicitly and every class has an (implicit) constructor.</simpara>
-<simpara>For a given a class <literal>C</literal>, the constructor is available via two properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>C</mi><mi>t</mi><mi>o</mi><mi>r</mi></math></term>
-<listitem>
-<simpara>the explicitly defined constructor (if any).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math></term>
-<listitem>
-<simpara>the explicit or implicit constructor.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>If <literal>C</literal> is provided with an explicit constructor, we have <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>=</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>C</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>C</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>∈</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math>.
-Note that <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>∉</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi></math> in all cases.</simpara>
-<simpara>The return type of the constructor of a class <literal>C</literal> is <literal>C</literal>.
-If <literal>C</literal> has type parameters <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></math>, then the return type is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo><</mo><msub><mi>T</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub><mo>></mo></math>. The constructor is called with the operator.
-Since the return type of a constructor is implicitly defined by the class, it is to be omitted.
-By this definition, a constructor looks like the following:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public constructor(s: string) {
- // init something
- }
-}</programlisting>
-<simpara>Constructors define a variable execution environment and therefore provide access to the actual passed-in parameters through the implicit variable inside of their bodies (c.f. <xref linkend="_arguments-object"/>).</simpara>
-<requirement xml:id="IDE-56">
-<title>Defining and Calling Constructors</title>
-<simpara>
-<anchor xml:id="Req-IDE-56" xreflabel="[Req-IDE-56]"/>
-<emphasis role="strong">Requirement: IDE-56:</emphasis>
-<link linkend="Req-IDE-56">Defining and Calling Constructors</link> (ver. 1)</simpara>
- <simpara>
-
-For a constructor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> of a class <literal>C</literal>, the following conditions
-must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> must neither be abstract nor static nor final and it must not be annotated with <literal>@Override</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>If a class does not explicitly define a constructor then the constructor’s signature of the superclass constructor is assumed.</simpara>
-</listitem>
-<listitem>
-<simpara>If a class defines a constructor with formal parameters then this constructor has to be called explicitly in constructors defined in subclasses.</simpara>
-</listitem>
-<listitem>
-<simpara>If a super constructor is called explicitly, this call must be the only expression of an expression statement which has to be the first statement of the body.</simpara>
-</listitem>
-<listitem>
-<simpara>Constructors may appear in interfaces, but some restrictions apply:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>constructors in interfaces must not have a body.</simpara>
-</listitem>
-<listitem>
-<simpara>constructors in interfaces or their containing interface or one of its direct or indirect super interfaces must be annotated with <literal>@CovariantConstructor</literal>.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>A constructor must not have an explicit return type declaration.</simpara>
-</listitem>
-<listitem>
-<simpara>The implicit return type of a constructor is <literal>this?</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>A constructor must not have any type parameters.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Properties of object literals may be called <literal>constructor</literal>.
-However they are not recognized as constructors in these cases.</simpara>
-<requirement xml:id="IDE-57">
-<title>Initialization of Final Fields in the Constructor</title>
-<simpara>
-<anchor xml:id="Req-IDE-57" xreflabel="[Req-IDE-57]"/>
-<emphasis role="strong">Requirement: IDE-57:</emphasis>
-<link linkend="Req-IDE-57">Initialization of Final Fields in the Constructor</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Required attributes must be initialized:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>a</mi><mo>∈</mo><mi>C</mi><mo>.</mo><mi>a</mi><mi>t</mi><mi>t</mi><mi>r</mi><mi>:</mi><mi>a</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>q</mi><mi>u</mi><mi>i</mi><mi>r</mi><mi>e</mi><mi>d</mi><mo>⇒</mo><mo>∃</mo><mi>e</mi><mo>∈</mo><mi>r</mi><mo>.</mo><mi>e</mi><mi>l</mi><mi>e</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mi>:</mi><mi>a</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>e</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Note on syntax: ECMAScript 6 defines constructors similarly, [<link linkend="ECMA15a">ECMA15a(p.S13.5)</link>]. In
-ECMAScript 6 the super constructor is not called automatically as well.</simpara>
-<simpara>The super literal used in order to call super methods is further
-described in <xref linkend="_the-super-keyword"/>.</simpara>
-<section xml:id="_structural-this-type-in-constructor">
-<title>Structural This Type in Constructor</title>
-<simpara>The use of a structural this reference as a formal parameter type is possible only in constructors.
-This parameter can be annotated with <literal>@Spec</literal> which causes the compiler to generate initialization code.</simpara>
-<simpara>Simply using <literal>this</literal> as a type in the constructor causes the constructor to require an object providing all public fields of the class for initialization purposes.
-The fields have to be set manually as shown in the following code snippet.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A{
- public s: string;
- public constructor(src: ~~this) {
- this.s = src.s;
- }
-}</programlisting>
-<simpara>Remarks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The type of the formal parameter <literal>~~this</literal> refers to the structural field type, see <xref linkend="_structural-typing"/> for details on structural typing.
-It contains all public fields of the type.</simpara>
-</listitem>
-<listitem>
-<simpara>Subclasses may override the constructor and introduce additional parameters.
-They have to call the super constructor explicitly, however, providing a parameter with at least all required attributes of the superclass.
-Usually the type <literal>this</literal> is replaced with the actual subclass, but in the case of a <literal>super()</literal> call the <literal>this</literal> type of structural formal parameters is replaced with the <literal>this</literal> type of the superclass,
-hence only required fields of the superclass must be present.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>As with other structural references, it is possible to add the structural reference with additional structural members, which can be used to initialize private fields which
-become not automatically part of the structural field type. For example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A{
- public s: string;
- private myPrivateNumber: number;
- public constructor(src: ~~this with { x: number; }) {
- this.s = src.s;
- this.myPrivateNumber = src.x;
- }
-}</programlisting>
-<simpara>Defining additional members may become a problem if a subclass defines public fields with the same name, as the <literal>~~this</literal> type will contain these fields in the subclass.
-This is marked as an error in the subclass.</simpara>
-<requirement xml:id="IDE-58">
-<title>Names of additional members of structural this type in constructor</title>
-<simpara>
-<anchor xml:id="Req-IDE-58" xreflabel="[Req-IDE-58]"/>
-<emphasis role="strong">Requirement: IDE-58:</emphasis>
-<link linkend="Req-IDE-58">Names of additional members of structural this type in constructor</link> (ver. 1)</simpara>
- <simpara>
-
-If the structural this type is used in a constructor of a class <literal>C</literal>, and if this structural reference contains an additional structural member <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mi>M</mi></math>, the following constraints must hold true:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>For any subclass <literal>S</literal> of <literal>C</literal>, with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>=</mo><mi>C</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> (the subclass does not define its own constructor), <literal>S</literal> must not contain a public member with same name as <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mi>M</mi></math>:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo><</mo><mi>:</mi><mi>C</mi><mo>,</mo><mi>S</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>=</mo><mi>C</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0em"/><mo>⇒</mo><mo>∄</mo><mi>M</mi><mo>∈</mo><mi>S</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi></math>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="5.0em"/><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>∧</mo><mi>M</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>S</mi><mi>M</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara><literal>C</literal> itself must not contain a public member with same name as <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mi>M</mi></math>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∄</mo><mi>M</mi><mo>∈</mo><mi>C</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>∧</mo><mi>M</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>S</mi><mi>M</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math>
-</listitem>
-</orderedlist>
-</requirement>
-<example>
-<title>Field name conflicts with structural member name</title>
-<simpara>The situation described in <xref linkend="Req-IDE-58"/> is demonstrated in the following code fragment:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- private myPrivateNumber: number;
- public constructor(src: ~~this with { x: number; }) {
- this.myPrivateNumber = src.x;
- }
-}
-
-class B extends A {
- public x: number; // will cause an error message
-}</programlisting>
-</example>
-</section>
-<section xml:id="spec-constructor">
-<title>@Spec Constructor</title>
-<simpara>The tedious process of copying the members of the parameter to the fields of the class can be automated via the <literal>@Spec</literal>
-annotation if the argument has <literal>~i~this</literal> structural initializer field typing. More details about this typing can be
-found in <xref linkend="structural-readWriteInit-field-typing"/>. This can be used as shown in the following listing:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- public field: string;
- public constructor(@Spec spec: ~i~this) {}
-}
-let a = new A({field: 'hello'});
-console.log(a.field); // prints: hello</programlisting>
-<simpara>The code for initializing the public field of <literal>A</literal> is automatically generated, thanks to the <literal>@Spec</literal> annotation being
-given in the constructor.</simpara>
-<requirement xml:id="IDE-59">
-<title>@Spec Constructor</title>
-<simpara>
-<anchor xml:id="Req-IDE-59" xreflabel="[Req-IDE-59]"/>
-<emphasis role="strong">Requirement: IDE-59:</emphasis>
-<link linkend="Req-IDE-59">@Spec Constructor</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Annotation <literal>@Spec</literal> may only appear on a formal parameter of a constructor. Such a formal parameter is then called
-<emphasis>@Spec parameter</emphasis> or simply <emphasis>spec parameter</emphasis> and its owning constructor is referred to as a <emphasis>@Spec constructor</emphasis> or
-<emphasis>spec constructor</emphasis>. An argument to the spec parameter is called <emphasis>spec object</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara>Only a single formal parameter of a constructor may be annotated with <literal>@Spec</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>If a formal parameter is annotated with <literal>@Spec</literal>, the parameter’s type must be <literal>~i~this</literal> (i.e. a use-site
-structural initializer field type of <literal>this</literal>, see <xref linkend="structural-readWriteInit-field-typing"/>).</simpara>
-</listitem>
-<listitem>
-<simpara>Using the data provided in the spec object, i.e. in the argument to the spec parameter, a spec constructor will
-automatically initialize</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>all <emphasis role="strong">owned</emphasis> data fields and <emphasis role="strong">owned</emphasis> setters of the containing class, and</simpara>
-</listitem>
-<listitem>
-<simpara>all data fields and setters from interfaces implemented by the containing class</simpara>
-</listitem>
-</orderedlist>
-<simpara>if and only if those members are also part of the spec parameter’s structural initializer field type.</simpara>
-</listitem>
-<listitem>
-<simpara>Fields explicitly added to the spec parameter, e.g. <literal>@Spec spec: ~i~this with {name:string}</literal>, are used for initialization
-if a non-public field of the same name exists in the class, either as an owned member or from an implemented interface.
-The type of such an additional field must be a subtype of the declared type of the field being initialized:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>s</mi><mo>∈</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mo>.</mo><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><mo>∃</mo><mi>f</mi><mo>∈</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mo>⇒</mo><mi>Γ</mi><mo>⊢</mo><mi>s</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>f</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Even if the <literal>@Spec</literal> annotation is used, the super constructor must be invoked explicitly (as usual).</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>It follows from no. 4 above that</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>non-public data fields and setters are never initialized (because they will never be part of the spec parameter’s
-structural initializer field type),</simpara>
-</listitem>
-<listitem>
-<simpara>properties provided in the spec object but not defined in the parameter’s structural initializer field type, are
-<emphasis>not</emphasis> used for initialization, even if a (protected or private) field of the same name exists in the class,</simpara>
-</listitem>
-<listitem>
-<simpara>data fields and setters inherited from a super class are never initialized by a spec constructor (instead, this will
-happen in the spec constructor of the super class).</simpara>
-</listitem>
-</orderedlist>
-<simpara>The last of these implications will be detailed further at the end of the coming section.</simpara>
-<simpara><emphasis role="strong">@Spec Constructors and Inheritance</emphasis></simpara>
-<simpara>Spec constructors are inherited by subclasses that do not have a constructor and, when creating instances of the
-subclass, will then require properties for writable public fields of the subclass in the spec object <emphasis role="strong">and</emphasis> include
-initialization code for them.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- public fa;
- public constructor(@Spec spec: ~i~this) {}
-}
-class B extends A {
- public fb;
-}
-
-const b = new B({fa: 'hello', fb: 'world'}); // requires & initializes fb too!
-console.log(b.fa); // prints: hello
-console.log(b.fb); // prints: world</programlisting>
-<simpara>Public writable fields from implemented interfaces are included as well, i.e. required as property in spec object <emphasis role="strong">and</emphasis>
-initialized by auto-generated code in the <literal>@Spec</literal> constructor:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface I {
- public fi;
-}
-class B implements I {
- public fb;
- public constructor(@Spec spec: ~i~this) {}
-}
-
-const a = new B({fb: 'hello', fi: 'world'}); // requires & initializes fi too!
-console.log(a.fb); // prints: hello
-console.log(a.fi); // prints: world</programlisting>
-<simpara>When having a spec constructor in a class <literal>B</literal> that extends a super class <literal>A</literal> without an owned or inherited spec
-constructor, it should be noted that the <literal>~i~this</literal> type will require properties for public writable fields of <literal>A</literal>,
-but the initialization code automatically generated due to the <literal>@Spec</literal> annotation will <emphasis role="strong">not</emphasis> initialize those members.
-For public writable fields from an interface <literal>I</literal> implemented by <literal>B</literal>, however, both a property will be required by
-<literal>~i~this</literal> <emphasis role="strong">and</emphasis> initialization code will be generated in the <literal>@Spec</literal> constructor. This is illustrated in the
-following code example.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- public fa;
-}
-interface I {
- public fi;
-}
-class B extends A implements I {
- public fb;
- public constructor(@Spec spec: ~i~this) { // <- fa, fi, fb required in spec object
- // Constructor is responsible for initializing fa, fi, fb.
- // The @Spec annotation will generate initialization code
- // for fb and fi, but not for fa!
- }
-}
-
-let b = new B({
- fa: 'hello', // <- fa is required (removing it would be a compile error)
- fi: 'world',
- fb: '!!'
-});
-
-console.log(b.fa); // undefined
-console.log(b.fi); // world
-console.log(b.fb); // !!</programlisting>
-<simpara>The rationale for this different handling of fields from super classes and implemented interfaces is
-1. fields from an implemented interface are not seen as inherited but rather implemented by implementing class, so from
- the <literal>@Spec</literal> annotation’s perspective the field is a field of the implementing class, and
-2. in case of a field inherited from a super class the correct way of initialization may depend on details of the super
- class and has to be taken care of by custom code in the constructor of the subclass (usually by invoking the non-<literal>@Spec</literal>
- constructor of the superclass with <literal>super</literal>).</simpara>
-<simpara><emphasis role="strong">Special Use Cases</emphasis></simpara>
-<simpara>The following examples illustrate further details of other use cases of spec constructors.</simpara>
-<example>
-<title>Anonymous Interface in Constructor</title>
-<simpara>The base class <literal>A</literal> in the examples redefines the constructor already defined in <literal>N4Object</literal>. This is not
-generally necessary and is only used here to make the example legible.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- public s: string;
- public constructor(@Spec spec: ~i~this) {
- // initialization of s is automatically generated
- }
-}
-class B extends A {
- public t: string;
- private n: number;
- public constructor(spec: ~~this with {n: number;}) {
- super(spec); // only inherited field s is set in super constructor
- }
-}</programlisting>
-</example>
-<example>
-<title>Spec Object and Subclasses</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A1 {
- public s: string;
- public n: number;
- public constructor(@Spec spec: ~i~this) {}
-}
-class B extends A1 {
- public constructor() {
- super({s:"Hello"}); // <-- error, n must be set in object literal
- }
-}
-class C extends A1 {
- public constructor() {
- super({s:"Hello"}); // <-- error, n must be set in object literal
- this.n = 10; // <-- this has no effect on the super constructor!
- }
-}
-
-class A2 {
- public s: string;
- public n: number?; // now n is optional!
- public constructor(@Spec spec: ~i~this) {}
-}
-class D extends A2 {
- public constructor() {
- super({s:"Hello"}); // and this is ok now!
- this.n = 10; // this explains why it is optional
- }
-}
-
-class A3 {
- public s: string;
- public n: number = 10; // now n is not required in ~~this
- public constructor(@Spec spec: ~i~this) {}
-}
-class E extends A3 {
- public constructor() {
- super({s:"Hello"}); // and this is ok now!
- }
-}</programlisting>
-<simpara>The last case (class E) demonstrates a special feature of the typing strategy modifier in combination with the <literal>this</literal> type, see <xref linkend="_structural-typing"/> for details.</simpara>
-<simpara>The constructor in class <literal>B</literal> contains an error because the super constructor expects all required attributes in <literal>A1</literal> to be set.
-The additional initialization of the required field <literal>A1.n</literal> as seen in <literal>C</literal> does not change that expectation.
-In this example, the field <literal>n</literal> should not have been defined as required in the first place.</simpara>
-<simpara>Optional fields like <literal>n?</literal> in class <literal>A2</literal> or fields with default values like <literal>n=10</literal> in class <literal>A3</literal> are not required to be part of the <literal>spec</literal> object.</simpara>
-</example>
-<example>
-<title>Superfluous Properties in @Spec Constructors</title>
-<simpara>Each non-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></math> field has to be set in the constructor via the <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>with</mtext></mstyle></math> to the parameter otherwise properties are <emphasis>not</emphasis> used to set non-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></math> fields.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public s: string;
- n: number;
- constructor(@Spec spec: ~i~this) {}
-}
-
-// n is ignored here
-new C( { s: "Hello", n: 42 });
-
-// but:
-var ol = { s: "Hello", n: 42 };
-// "ol may be used elsewhere, we cannot issue warning here" at "ol"
-new C(ol) ;
-
-// of course this is true for all superfluous properties
-// weird is not used in constructor
-new C( { s: "Hello", weird: true } );</programlisting>
-</example>
-<variablelist>
-<varlistentry>
-<term>Restriction when initializing interface fields via @Spec constructor <anchor xml:id="restriction-interface-field-spec-constructor" xreflabel="[restriction-interface-field-spec-constructor]"/> </term>
-<listitem>
-<simpara>In most cases, interface definitions in <literal>n4jsd</literal> files simply declare functions and fields that are supposed to be provided by the runtime environment.
-As a result, there are restrictions as to whether fields of interfaces defined in <literal>n4jsd</literal> files can initialized via <literal>@Spec</literal> constructors or not.
-In particular, fields of an interface declared in a <literal>n4jsd</literal> file cannot be initialized via @Spec constructor if the interface</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>is a built-in or</simpara>
-</listitem>
-<listitem>
-<simpara>does not have an <literal>@N4JS</literal> annotation</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The following example illustrates this restriction.</simpara>
-<example>
-<title>Interface fields that cannot be initialized via @Spec constructors</title>
-<formalpara>
-<title>Inf.n4jsd</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">export external interface I {
- public m: string;
-}
-
-@N4JS
-export external interface J {
- public n: string;
-}</programlisting>
-</para>
-</formalpara>
-<formalpara>
-<title>Test.n4js</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">import { I } from "Inf";
-// I is an external interface WITHOUT @N4JS annotation
-class C implements I {
- constructor(@Spec spec:~i~this) {}
-}
-
-// J is an external interface with @N4JS annotation
-class D implements J {
- constructor(@Spec spec:~i~this) {}
-}
-
-// XPECT warnings --> "m is a property of built-in / provided by runtime / external without @N4JS annotation interface I and can not be initialized in Spec constructor." at "m"
-let c:C = new C({m: "Hello"});
-
-// XPECT nowarnings
-let d:D = new D({n: "Bye"});
-
-console.log(c.m)
-console.log(d.n)
-
-/* XPECT output ---
-<==
-stdout:
-undefined
-Bye
-stderr:
-==>
---- */</programlisting>
-</para>
-</formalpara>
-</example>
-<simpara>In this example, the interface <literal>I</literal> is defined in the <literal>Inf.n4jsd</literal> file without the <literal>@N4JS</literal> annotation. As a result, its field <literal>m</literal> cannot be initialized via the <literal>@Spec</literal> constructor and hence the output of <literal>console.log(c.m)</literal> is <literal>undefined</literal>. On the other hand, since the interface <literal>J</literal> is declared with the annotation <literal>@N4JS</literal>, it is possible to initialize its field <literal>n</literal> in the <literal>@Spec</literal> constructor. That’s why the result of <literal>console.log(d.n)</literal> is <literal>Bye</literal>.</simpara>
-</section>
-<section xml:id="_callable-constructors">
-<title>Callable Constructors</title>
-
-</section>
-<section xml:id="_covariant-constructors">
-<title>Covariant Constructors</title>
-<simpara>Usually, the constructor of a subclass need not be override compatible with the constructor of its super class.
-By way of annotation <literal>@CovariantConstructor</literal> it is possible to change this default behavior and enforce all subclasses to have constructors with override compatible signatures.
-A subclass can achieve this by either inheriting the constructor from the super class (which is usually override compatible,
-with the special case of <literal>@Spec</literal> constructors) or by defining a new constructor with a signature compatible to the inherited constructor.
-The same rules as for method overriding apply.</simpara>
-<simpara>The <literal>@CovariantConstructor</literal> annotation may be applied to the constructor, the containing classifier, or both.
-It can also be used for interfaces; in fact, constructors are allowed in interfaces only if they themselves or the interface is annotated with <literal>@CovariantConstructor</literal> (see <xref linkend="Req-IDE-60"/>).</simpara>
-<definition>
-<title>Covariant Constructor</title>
-<simpara>
-<anchor xml:id="covariant_constructor" xreflabel="[covariant_constructor]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="covariant_constructor">Covariant Constructor</link></simpara>
-<simpara>
-
-A classifier <literal>C</literal> is said to <literal><emphasis>have a covariant constructor</emphasis></literal> if and
-only if one of the following applies:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>C</literal> has a direct super class <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>C</mi><mi>'</mi></msup></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>C</mi><mi>'</mi></msup></math> is annotated with <literal>@CovariantConstructor</literal> or <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>C</mi><mi>'</mi></msup></math> has a constructor annotated with <literal>@CovariantConstructor</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>C</literal> has a directly implemented interface <literal>I and `I</literal> is annotated with <literal>@CovariantConstructor</literal> or <literal>I</literal> has a constructor annotated with <literal>@CovariantConstructor</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>C</literal> has a direct super class or directly implemented interface that <literal><emphasis>has a covariant constructor</emphasis></literal> (as defined here).</simpara>
-</listitem>
-</orderedlist>
-</definition>
-<simpara>Note that <literal>C</literal> does not need to have an owned(!) constructor; also a constructor inherited from a super class can be declared covariant.</simpara>
-<simpara>The following rules apply to covariant constructors.</simpara>
-<requirement xml:id="IDE-60">
-<title>Covariant Constructors</title>
-<simpara>
-<anchor xml:id="Req-IDE-60" xreflabel="[Req-IDE-60]"/>
-<emphasis role="strong">Requirement: IDE-60:</emphasis>
-<link linkend="Req-IDE-60">Covariant Constructors</link> (ver. 1)</simpara>
- <simpara>
-
-. Annotation <literal>@CovariantConstructor</literal> may only be applied to classes, interfaces, and constructors.
-Annotating a constructor with this annotation, or its containing classifier, or both have all the same effect.
-. Given a class <literal>C</literal> with an owned constructor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> and a super class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mi>u</mi><mi>p</mi></math> that has a covariant constructor (owned or inherited, see <xref linkend="_covariant-constructors"/>),
-then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mi>u</mi><mi>p</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> must be accessible from <literal>C</literal>,
-.. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> must be override compatible with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math>:</simpara>
-<simpara>+
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><mrow><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></mrow><mrow><mi>S</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></mrow></mfenced></math></simpara>
-<simpara>+
-This constraint corresponds to <xref linkend="Req-IDE-72"/> except for the <literal>Override</literal> annotation which is not required here.
-. Given a classifier <literal>C</literal> implementing interface <literal>I</literal> and <literal>I</literal> has a covariant constructor (owned or inherited, see <xref linkend="_covariant-constructors"/>), we require
-.. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> must be accessible from <literal>C</literal>,
-.. an implementation-compatible constructor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> must be defined in C with</simpara>
-<simpara>+
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><mrow><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></mrow><mrow><mi>I</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></mrow></mfenced></math></simpara>
-<simpara>+
-This constraint corresponds to <xref linkend="Req-IDE-74"/> except for the <literal>@Override</literal> annotation, which is not required, here.
-.. Given a classifier <literal>C</literal> without an owned constructor and an extended class or interface <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mi>u</mi><mi>p</mi></math> that has a covariant constructor (owned or inherited, see <xref linkend="_covariant-constructors"/>),
-we require the inherited constructor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> of <literal>C</literal> within the context of <literal>C</literal> to be override compatible to itself in the context of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mi>u</mi><mi>p</mi></math>.
-Using notation <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mfenced close="]" open="["><mi>T</mi></mfenced></math> to denote that a member <literal>M</literal> is to be treated as defined in container type <literal>T</literal>, which means the this-binding is set to <literal>T</literal>, we can write:</simpara>
-<simpara>+
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><mrow><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mfenced close="]" open="["><mi>C</mi></mfenced></mrow><mrow><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mfenced close="]" open="["><mrow><mi>S</mi><mi>u</mi><mi>p</mi></mrow></mfenced></mrow></mfenced></math></simpara>
-<simpara>+
-This constraint does not correspond to any of the constraints for the redefinition of ordinary members.</simpara>
-</requirement>
-<simpara>The following example demonstrates a use case for covariant constructors.
-It shows a small class hierarchy using covariant constructors, <literal>Cls</literal> and <literal>Cls2</literal>, together with a helper function <literal>createAnother</literal> that creates and returns a new instance of the same type as its argument <literal>value</literal>.</simpara>
-<example xml:id="ex:covariant_constructors">
-<title>Covariant Constructors</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A {}
-class B extends A {}
-
-@CovariantConstructor
-class Cls {
- constructor(p: B) {}
-}
-class Cls2 extends Cls {
- constructor(p: A) { // it's legal to generalize the type of parameter 'p'
- super(null);
- }
-}
-
-function <T extends Cls> createAnother(value: T, p: B): T {
- let ctor = value.constructor;
- return new ctor(p);
-}
-
-let x = new Cls2(new A());
-let y: Cls2;
-
-y = createAnother(x, new B());</programlisting>
-</example>
-<simpara>In the code of <xref linkend="ex:covariant_constructors"/>, we would get an error if we changed the type of parameter <literal>p</literal> in the constructor of <literal>Cls2</literal> to some other type that
-is not a super type of <literal>B</literal>, i.e. the type of the corresponding parameter of <literal>Cls</literal>’s constructor.
-If we removed the <literal>@CovariantConstructor</literal> annotation on <literal>Cls</literal>, we would get an error in the new expression inside function <literal>createAnother</literal>.</simpara>
-<simpara>The next example illustrates how to use <literal>@CovariantConstructor</literal> with interfaces and shows a behavior that might be surprising at first sight.</simpara>
-<example xml:id="ex:covariant-constructors-in-interfaces">
-<title>Covariant Constructors in Interfaces</title>
-<programlisting language="n4js" linenumbering="unnumbered">@CovariantConstructor
-interface I {
- constructor(p: number)
-}
-
-class C implements I {
- // no constructor required!
-}
-
-class D extends C {
- // XPECT errors --> "Signature of constructor of class D does not conform to overridden constructor of class N4Object: {function(number)} is not a subtype of {function()}." at "constructor"
- constructor(p: number) {}
-}</programlisting>
-</example>
-<simpara>Interface <literal>I</literal> declares a covariant constructor expecting a single parameter of type <literal>number</literal>.
-Even though class <literal>C</literal> implements <literal>I</literal>, it does not need to define an owned constructor with such a parameter.
-According to <xref linkend="Req-IDE-60"/>, it is enough for <literal>C</literal> to have a constructor, either owned or inherited, that is override compatible with the one declared by <literal>I</literal>.
-Class <literal>C</literal> inherits the default constructor from <literal>N4Object</literal>, which does not have any arguments and is thus override compatible to <literal>I</literal>’s constructor.</simpara>
-<simpara>In addition, subclasses are now required to have constructors which are override compatible with the constructor of class <literal>C</literal>, i.e. the one inherited from <literal>N4Object</literal>.
-<xref linkend="ex:covariant-constructors-in-interfaces"/> shows that this is violated even when repeating the exact same constructor signature from interface <literal>I</literal>,
-because that constructor now appears on the other side of the subtype test during checking override compatibility.</simpara>
-</section>
-</section>
-<section xml:id="_data-fields" role="language-n4js">
-<title>Data Fields</title>
-<simpara>A data field is a simple property of a class.
-There must be no getter or setter defined with the same name as the data field.
-In ECMAScript 6, a class has no explicit data fields.
-It is possible, however, to implicitly define a data field by simply assigning a value to a variable of the this element (e.g. <literal>this.x = 10</literal> implicitly defines a field <literal>x</literal>).
-Data fields in N4JS are similar to these implicit fields in ECMAScript 6 except that they are defined explicitly in order to simplify validation and user assistance.</simpara>
-<section xml:id="data-fields-syntax">
-<title>Syntax</title>
-<programlisting language="xtext" linenumbering="unnumbered">N4FieldDeclaration <Yield>:
- {N4FieldDeclaration}
- FieldDeclarationImpl<Yield>
-;
-
-fragment FieldDeclarationImpl <Yield>*:
- (declaredModifiers+=N4Modifier)* BogusTypeRefFragment?
- declaredName=LiteralOrComputedPropertyName<Yield>
- (declaredOptional?='?')?
- ColonSepTypeRef?
- ('=' expression=Expression<In=true,Yield>)?
- Semi
-;</programlisting>
-</section>
-<section xml:id="data-fields-properties">
-<title>Properties</title>
-<simpara>Fields have the following properties which can be explicitly defined:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>declaredOptional</literal> </term>
-<listitem>
-<simpara>Tells whether the accessor was declared optional.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>typeRef</literal> </term>
-<listitem>
-<simpara>Type of the field; default value is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>A</mi><mi>n</mi><mi>y</mi></math>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>expr</literal> </term>
-<listitem>
-<simpara>Initializer expression, i.e. sets default value.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>static</literal> </term>
-<listitem>
-<simpara>Boolean flag set to true if field is a static field.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>const</literal> </term>
-<listitem>
-<simpara>Boolean flag set to true if field cannot be changed. Note that const fields are automatically static.
-Const fields need an initializer. Also see <xref linkend="_assignment-modifiers"/>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<note>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi></math> is <emphasis>not</emphasis> the (reversed) value of the property descriptor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>w</mi><mi>r</mi><mi>i</mi><mi>t</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math> as the latter is checked at runtime while const may or may not be checked at runtime.</simpara>
-</note>
-<simpara>The following pseudo properties are defined via annotations for setting the values of the property descriptor:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>enumerable</literal> </term>
-<listitem>
-<simpara>Boolean flag reflecting the property descriptor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>n</mi><mi>u</mi><mi>m</mi><mi>e</mi><mi>r</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math>, set via annotation <literal>@Enumerable(true|false)</literal>.
-The default value is <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>.<footnote><simpara>version 4.0</simpara></footnote></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>declaredWriteable</literal> </term>
-<listitem>
-<simpara>Boolean flag reflecting the property descriptor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>w</mi><mi>r</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math>, set via annotation <literal>@Writeable(true|false)</literal>.
-The default value is <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>.<footnote><simpara>This cannot be done w/o <literal>null</literal>/<literal>undefined</literal> analysis</simpara></footnote></simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>final</literal> </term>
-<listitem>
-<simpara>Boolean flag making the field read-only, and it must be set in the constructor. Also see <xref linkend="_assignment-modifiers"/>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="data-fields-derived-values" renderas="sect5">Derived values for fields</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>readable</literal> </term>
-<listitem>
-<simpara>Always true for fields.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>abstract</literal> </term>
-<listitem>
-<simpara>Always false for fields.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>writeable</literal> </term>
-<listitem>
-<simpara>Set to false if field is declared const or final. In the latter case, it may be set in the constructor (cf. <xref linkend="_assignment-modifiers"/>).</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<section xml:id="data-fields-semantics">
-<title>Semantics</title>
-<requirement xml:id="IDE-61">
-<title>Attributes</title>
-<simpara>
-<anchor xml:id="Req-IDE-61" xreflabel="[Req-IDE-61]"/>
-<emphasis role="strong">Requirement: IDE-61:</emphasis>
-<link linkend="Req-IDE-61">Attributes</link> (ver. 1)</simpara>
- <simpara>
-
-For any attribute <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi></math> if a
-class <literal>C</literal>, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A required data field must not define an initializer:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>q</mi><mi>u</mi><mi>i</mi><mi>r</mi><mi>e</mi><mi>d</mi><mo>⇒</mo><mi>a</mi><mo>.</mo><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mo>=</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>There must be no other member with the same name of a data field <literal>f</literal>.
-In particular, there must be no getter or setter defined with the same name:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∀</mo><mi> </mi><mi>m</mi><mo>∈</mo><mi>f</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi><mi>m</mi><mo>≠</mo><mi>f</mi><mo>⇒</mo><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>≠</mo><mi>f</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math></simpara>
-</listitem>
-</orderedlist>
-<simpara>If a subclass should set a different default value, this has to be done in the constructor of the subclass.</simpara>
-<simpara>For the relation of data fields and field accessors in the context of extending classes or implementing interfaces see <xref linkend="_redefinition-of-members"/>.</simpara>
-</requirement>
-</section>
-<section xml:id="data-fields-type-inference">
-<title>Type Inference</title>
-<simpara>The type of a field is the type of its declaration:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>f</mi><mi>:</mi><mi>Γ</mi><mo>⊢</mo><mi>d</mi></mrow></mfrac></math>
-<simpara>The type of a field declaration is either the declared type or the inferred type of the initializer expression:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow><mi>d</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle><mspace width="3.0mm"/><mi>T</mi><mo>=</mo><mi>d</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>d</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow><mi>d</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle><mspace width="3.0mm"/><mi>d</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>d</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>E</mi><mo>=</mo><mi>Γ</mi><mo>⊢</mo><mi>d</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mspace width="3.0mm"/><mi>E</mi><mo>∉</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>null, undefined</mtext></mstyle></mfenced><mspace width="3.0mm"/><mi>T</mi><mo>=</mo><mi>E</mi><mi>}</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>d</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac></math></simpara>
-<simpara>If the type contains type variables they are substituted according to
-type parameters which are provided by the reference:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>t</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>:</mi><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>TField</mtext></mstyle><mi> </mi><mi>t</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-</section>
-</section>
-<section xml:id="_assignment-modifiers">
-<title>Assignment Modifiers</title>
-<simpara>Assignment of data fields can be modified by the assignment modifiers <literal>const</literal> (similar to constant variable declarations, see <xref linkend="_const"/>) and <literal>@Final</literal>.</simpara>
-<requirement xml:id="IDE-62">
-<title>Const Data Fields</title>
-<simpara>
-<anchor xml:id="Req-IDE-62" xreflabel="[Req-IDE-62]"/>
-<emphasis role="strong">Requirement: IDE-62:</emphasis>
-<link linkend="Req-IDE-62">Const Data Fields</link> (ver. 1)</simpara>
- <simpara>
-
-For a data field <literal>f</literal> marked as <literal>const</literal>, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>An initializer expression must be provided in the declaration (except in n4jsd files):<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara>A constant data field is implicitly static and must be accessed only via the classifier type.
-It is not possible, therefore, to use the <literal>this</literal> keyword in the initializer expression of a constant field:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∄</mo><mi>s</mi><mi>u</mi><mi>b</mi><mo>∈</mo><mi>f</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><msup><mi>r</mi><mo>*</mo></msup><mi>:</mi><mi>s</mi><mi>u</mi><mi>b</mi><mo>=</mo><mi>"</mi><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi><mi>"</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>A constant data field must not be annotated with <literal>@Final</literal>:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mo>→</mo><mo>¬</mo><mi>f</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Constant data fields are not writeable (cf. <xref linkend="Req-IDE-68"/>):<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mo>→</mo><mo>¬</mo><mi>f</mi><mo>.</mo><mi>w</mi><mi>r</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-63">
-<title>Final Data Fields</title>
-<simpara>
-<anchor xml:id="Req-IDE-63" xreflabel="[Req-IDE-63]"/>
-<emphasis role="strong">Requirement: IDE-63:</emphasis>
-<link linkend="Req-IDE-63">Final Data Fields</link> (ver. 1)</simpara>
- <simpara>
-
-For a data field <literal>f</literal> marked as <literal>@Final</literal>, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A final data field must not be modified with <literal>const</literal> or <literal>static</literal>:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>→</mo><mo>¬</mo><mi>f</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mo>∧</mo><mo>¬</mo><mi>f</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>S</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>A final data field is not writeable:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>→</mo><mo>¬</mo><mi>f</mi><mo>.</mo><mi>w</mi><mi>r</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math><?asciidoc-br?>
-A final field may, however, be set in the constructor.
-See <xref linkend="Req-IDE-68"/> for details.</simpara>
-</listitem>
-<listitem>
-<simpara>A final data field must be either initialized by an initializer expression or in the constructor.
-If the field is initialized in the constructor, this may be done either explicitly or via a spec style constructor.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mspace width="3.0mm"/><mi>f</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mo>∨</mo><mrow><mo>(</mo><mo>∃</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>:</mi><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>=</mo><mi>f</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></mrow></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mspace width="3.0em"/><mo>∧</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>"this"</mtext></mstyle></mtd></mtr><mtr><mtd><mrow><mspace width="3.0mm"/><mspace width="3.0em"/><mo>∧</mo><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mrow><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi></mrow><mi>f</mi></mfenced><mo>)</mo></mrow></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mo>∨</mo><mrow><mo>(</mo><mi>f</mi><mo>.</mo><mi>p</mi><mi>u</mi><mi>b</mi><mi>l</mi><mi>i</mi><mi>c</mi><mo>∧</mo><mo>∃</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mo>∈</mo><mi>f</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mi>:</mi></mrow></mtd></mtr><mtr><mtd><mrow><mspace width="3.0mm"/><mspace width="3.0em"/><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mo>.</mo><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mo>∧</mo><mo>∃</mo><mi>s</mi><mi>m</mi><mo>∈</mo><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi><mi>s</mi><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>f</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>)</mo></mrow></mtd></mtr></mtable></math>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="_field-accessors-getter-setter">
-<title>Field Accessors (Getter/Setter)</title>
-<simpara>Instead of a simple data field, a field can be defined by means of the getter and setter accessor methods.
-These accessor methods are similar to the accuser methods in object literals:</simpara>
-<section xml:id="field-acessors-syntax">
-<title>Syntax</title>
-<programlisting language="xtext" linenumbering="unnumbered">N4GetterDeclaration <Yield>:
- => ({N4GetterDeclaration}
- (declaredModifiers+=N4Modifier)*
- GetterHeader<Yield>)
- (body=Block<Yield>)? ';'?
-;
-
-fragment GetterHeader <Yield>*:
- BogusTypeRefFragment? 'get' -> declaredName=LiteralOrComputedPropertyName<Yield>
- (declaredOptional?='?')?
- '(' ')'
- ColonSepTypeRef?
-;
-
-N4SetterDeclaration <Yield>:
- =>({N4SetterDeclaration}
- (declaredModifiers+=N4Modifier)*
- 'set'
- ->declaredName=LiteralOrComputedPropertyName <Yield>
- )
- (declaredOptional?='?')?
- '(' fpar=FormalParameter<Yield> ')' (body=Block<Yield>)? ';'?
-;</programlisting>
-<simpara>Notes with regard to syntax: Although ECMAScript 6 does not define fields in classes, it defines getter and setter methods similarly (cf. [<link linkend="ECMA15a">ECMA15a(p.S13.3, p.p.209)</link>]).</simpara>
-<example>
-<title>Getter and Setter</title>
-<simpara>The getter and setter implementations usually reference data fields internally.
-These are to be declared explicitly (although ECMAScript allows creating fields on the fly on their first usage).
-The following example demonstrates a typical usage of getter and setter in combination with a data field.
-The getter lazily initializes the field on demand.
-The setter performs some notification.</simpara>
-<formalpara>
-<title>Getter Setter</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class A {}
-
-class C {
- private _data: A = null;
-
- public get data(): A {
- if (this._data==null) {
- this._data = new A();
- }
- return this._data;
- }
-
- public set data(data: A) {
- this._data = data;
- this.notifyListeners();
- }
-
- notifyListeners(): void {
- // ...
- }
-}</programlisting>
-</para>
-</formalpara>
-</example>
-</section>
-<section xml:id="field-acessors-properties">
-<title>Properties</title>
-<simpara>Properties for field accessors:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>declaredOptional</literal> </term>
-<listitem>
-<simpara>Tells whether the accessor was declared optional.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>readable</literal> </term>
-<listitem>
-<simpara>Derived value: true for getters and false for setters.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>writable</literal> </term>
-<listitem>
-<simpara>Derived value: false for getters and true for setters.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="field-accessors-semantics">
-<title>Semantics</title>
-<simpara>There must be no field or method with the same name as a field accessor (follows from <xref linkend="Req-IDE-52"/>). In addition, the following constraints must hold:</simpara>
-<requirement xml:id="IDE-64">
-<title>Field Accessors</title>
-<simpara>
-<anchor xml:id="Req-IDE-64" xreflabel="[Req-IDE-64]"/>
-<emphasis role="strong">Requirement: IDE-64:</emphasis>
-<link linkend="Req-IDE-64">Field Accessors</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The return type of a getter must not be <literal>void</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The type of the parameter of a setter must not be <literal>void</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>If a getter <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>g</mi></math> is defined or consumed (from an interface) or merged-in (via static polyfill) in a class <literal>C</literal> and a setter <literal>S</literal> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>g</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>∧</mo><mi>s</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>=</mo><mi>g</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math> is inherited by
-<literal>C</literal> from one of its super classes, then <literal>C</literal> must define a setter <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>s</mi><mi>'</mi></msup></math> with
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>s</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>g</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>∧</mo><msup><mi>s</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>=</mo><mi>g</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math> <footnote><simpara>This is required, because in Javascript a getter shadows a corresponding setter defined further up in the prototype chain; likewise a setter shadows a corresponding getter.</simpara></footnote>.</simpara>
-</listitem>
-<listitem>
-<simpara>A setter must have exactly one formal parameter, i.e. variadic or default modifiers are not allowed.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The same applies to setters, accordingly.</simpara>
-<itemizedlist>
-<listitem>
-<simpara><xref linkend="Req-IDE-72"/>, <xref linkend="Req-IDE-73"/>, and <xref linkend="Req-IDE-74"/> apply to field accessors accordingly (getter / setter overriding).</simpara>
-</listitem>
-</itemizedlist>
-<note role="language-n4js">
-<simpara>A getter and setter with the same name need not have the same type, i.e. the getter’s return type need not be the same as a subtype of
-the type of the setter’s parameter (the types can be completely unrelated).<footnote><simpara>Thus, the type of one accessor is not used to infer the type of the other one. E.g., from <literal>set x(string s)</literal>, we cannot infer <literal>get x()</literal> to return <literal>string</literal> — instead, the getter is inferred to return <literal>any</literal>.</simpara></footnote></simpara>
-</note>
-</requirement>
-<simpara>Getters and setters – like functions – define a variable execution environment and therefore provide access to the actual passed-in parameters through the implicit <literal>arguments</literal>
-variable inside of their bodies (c.f. <xref linkend="_arguments-object"/>).</simpara>
-</section>
-</section>
-<section xml:id="optional-fields">
-<title>Optional Fields</title>
-<simpara>Data fields and field accessors of a classifier C can be declared optional, meaning that a structural subtype of C
-need not provide this field, but if it does, the field must be of correct type. However, to ensure overall type safety,
-the scope of application of this optionality is limited to a small number of specific use cases, as described in the
-following.</simpara>
-<section xml:id="_syntax-6">
-<title>Syntax</title>
-<simpara>To denote a data field or accessor as optional, a question mark is placed right after the name:</simpara>
-<formalpara>
-<title>Syntax of optional fields</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public field?: string;
-
- public get getter?(): number {
- return 42;
- }
- public set setter?(value: number) {}
-}</programlisting>
-</para>
-</formalpara>
-<simpara>The detailed grammar is given in the sections for data fields, cf. <xref linkend="data-fields-syntax"/>,
-and field accessors, cf. <xref linkend="field-acessors-syntax"/>.</simpara>
-</section>
-<section xml:id="_semantics-5">
-<title>Semantics</title>
-<simpara>It is important to note that the optionality of a field is, by default and in most cases, ignored and
-has an effect only in certain special cases.</simpara>
-<simpara>The effect of a field being optional is defined by the following requirement.</simpara>
-<requirement xml:id="IDE-240500">
-<title>Optional Fields</title>
-<simpara>
-<anchor xml:id="Req-IDE-240500" xreflabel="[Req-IDE-240500]"/>
-<emphasis role="strong">Requirement: IDE-240500:</emphasis>
-<link linkend="Req-IDE-240500">Optional Fields</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>By default, a data field, getter, or setter that is declared optional is handled in the
-exact same way as if no optionality were involved (i.e. by default, optionality is ignored).</simpara>
-<simpara>Optionality has an effect only in case of structural subtype checks <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi><mo><</mo><mi>:</mi><mi>R</mi></math> in which
-the left-hand side is one of the following:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>an object literal.</simpara>
-</listitem>
-<listitem>
-<simpara>a new expression.</simpara>
-</listitem>
-<listitem>
-<simpara>an instance of a final class, i.e. the type of the value on left-hand side must be nominal and refer to a final class.</simpara>
-</listitem>
-<listitem>
-<simpara>a reference to a const variable if its initializer expression is one of the following:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>an object literal.</simpara>
-</listitem>
-<listitem>
-<simpara>a new expression.</simpara>
-</listitem>
-<listitem>
-<simpara>an instance of a final class (as explained above).</simpara>
-</listitem>
-<listitem>
-<simpara>an ternary expression</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-<simpara>and then</simpara>
-<itemizedlist>
-<listitem>
-<simpara>in cases 1 and 4a, <emphasis role="strong">both</emphasis> fields and accessors (getters and setters) are optional.
-That means, an optional data field, getter, or setter of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> needs not be present in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>in cases 2, 3, 4b, and 4c, only <emphasis role="strong">getters</emphasis> are optional, setters are not optional.
-That means, an optional getter of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> needs not be present in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math> and an optional field of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> requires only a setter in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math>. Note that these cases are more restricted than the cases 1 and 4a.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Moreover, optionality has an effect in case of ternary expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi><mo><</mo><mi>:</mi><mi>R</mi></math> in which the left-hand side is a ternary expression, e.g. <literal>l = b? trueExpr : falseExpr</literal> whose <literal>trueExpr</literal> or <literal>falseExpr</literal> possibly recursively contains an expression of the kind mentioned above. In this case, the optionality effect is the more restricted optinality of <literal>trueExpr</literal> and <literal>falseExpr</literal>.</simpara>
-<simpara>If, according to these rules, a data field / getter / setter of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> need not be present in
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math> but a member with the same name and access is actually present in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math>, that member in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math>
-must be a data field / getter / setter of the same type / a subtype / a super type, respectively.
-In other words, if a not actually required member is present in the subtype, ordinary rules
-for member compatibility apply as if no optionality were involved (cf. general subtyping rules
-for structural types).</simpara>
-</requirement>
-<simpara>In other words, in object literals (cases 1 and 4a) neither optional getters, optional setters,
-nor optional data fields are required. However, in case of new expressions and instances of
-final classes (cases 2, 3, 4b, 4c) only optional getters are not required in a subtype;
-optional setters are required as normal (i.e. optionality ignored) and optional data fields
-require at least a setter.</simpara>
-<simpara>The following table summarizes the most common cases and shows how this relates to the different
-forms of structural typing.</simpara>
-<table xml:id="tab:optionalFields" frame="all" rowsep="1" colsep="1">
-<title>Optional Fields</title>
-<tgroup cols="8">
-<colspec colname="col_1" colwidth="25*"/>
-<colspec colname="col_2" colwidth="8.3333*"/>
-<colspec colname="col_3" colwidth="8.3333*"/>
-<colspec colname="col_4" colwidth="8.3333*"/>
-<colspec colname="col_5" colwidth="8.3333*"/>
-<colspec colname="col_6" colwidth="8.3333*"/>
-<colspec colname="col_7" colwidth="8.3333*"/>
-<colspec colname="col_8" colwidth="25.0002*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_6"><simpara>Δ</simpara></entry>
-<entry align="center" valign="top"><simpara>Case</simpara></entry>
-<entry align="left" valign="top"><simpara>Comment</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="center" valign="top"><simpara><literal>~</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>~~</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>~w~</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>~r~</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>~i~</literal></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_4"><simpara>may have setter</simpara></entry>
-<entry align="center" valign="top" namest="col_3" nameend="col_4"><simpara>never has setter</simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong"><literal>let x: ΔC = {};</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>1</simpara></entry>
-<entry align="left" valign="top"><simpara>nothing mandatory</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong"><literal>let x: ΔC = new D0();</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>2</simpara></entry>
-<entry align="left" valign="top"><simpara>setters mandatory</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong"><literal>let x: ΔC = new DG();</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>2</simpara></entry>
-<entry align="left" valign="top"><simpara>setters mandatory</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong"><literal>let x: ΔC = new DS();</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>2</simpara></entry>
-<entry align="left" valign="top"><simpara>setters mandatory</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong"><literal>let x: ΔC = fooD0();</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara>none</simpara></entry>
-<entry align="left" valign="top"><simpara>D0 not final</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong"><literal>let x: ΔC = fooSF0();</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara>none</simpara></entry>
-<entry align="left" valign="top"><simpara>fooSF0() not nominal</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong"><literal>let x: ΔC = fooF0();</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>✓</simpara></entry>
-<entry align="center" valign="top"><simpara>3</simpara></entry>
-<entry align="left" valign="top"><simpara>setters mandatory</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara>In the table, a "✓" means that the particular example is valid; in all other cases an error would
-be shown in N4JS source code. Here are the classes and functions used in the above table:</simpara>
-<formalpara>
-<title>Classes and functions used in table</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public field?: string;
-}
-
-class D0 {}
-
-class DG {
- public get field(): string { return "hello"; }
-}
-
-class DS {
- public set field(value: string) {}
-}
-
-@Final class F0 {}
-
-function fooD0(): D0 { return new D0(); }
-function fooSF0(): ~F0 { return new F0(); }
-function fooF0(): F0 { return new F0(); }</programlisting>
-</para>
-</formalpara>
-<simpara>It follows from the above definitions in Requirements <xref linkend="Req-IDE-240500"/> that cases 4a and 4b are not
-transitive across a chain of several <literal>const</literal> variables, whereas case 4c is transitive. For example:</simpara>
-<formalpara>
-<title>Transitivity of the use cases of optional fields</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public get getter?(): string {return null;}
-}
-class D {}
-@Final class F {}
-
-let c: ~C;
-
-
-// no transitivity via several const variables in use case "object literal":
-
-const ol1 = {};
-const ol2 = ol1;
-
-// XPECT errors --> "~Object is not a structural subtype of ~C: missing getter getter." at "ol2"
-c = ol2;
-
-
-// no transitivity via several const variables in use case "new expression":
-
-const new1 = new D();
-const new2 = new1;
-
-// XPECT errors --> "D is not a structural subtype of ~C: missing getter getter." at "new2"
-c = new2;
-
-
-// BUT: we do have transitivity via several const variables in use case "final nominal type":
-
-const finalNominal1 = new F();
-const finalNominal2 = finalNominal1;
-
-// XPECT noerrors -->
-c = finalNominal1;
-// XPECT noerrors --> "transitivity applies in this case"
-c = finalNominal2;</programlisting>
-</para>
-</formalpara>
-<simpara>The following example demonstrates how optionality behaves in ternay expressions.</simpara>
-<formalpara>
-<title>Optional fields in ternay expressions</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">interface ~I {
- public m?: int;
-}
-
-class ~C { }
-
-@Final class F { }
-
-let b: boolean;
-const cc: C = {}
-let f1 = new F();
-let f2: ~F = {};
-
-// True expression is a const object literal, so both fields and accessors in I are optional.
-// False expression is a new expression, so only getters in I are optionals.
-// As a result, only getters in I are optional.
-// XPECT errors --> "C is not a structural subtype of I: missing field m." at "b? cc : new C()"
-var te1: I = b? cc : new C()
-
-// No errors because both true and false expressions are object literal constants and hence
-// Both fields and accessors in I are optional.
-// XPECT noerrors
-var te2: I = b? cc : {}</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="_background">
-<title>Background</title>
-<simpara>The following example illustrates why optionality of fields has to be restricted
-to the few special cases defined above (i.e. object literals, new expressions, etc.).</simpara>
-<formalpara>
-<title>Problem 1 of optional fields</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public field?: string = "hello";
-}
-
-class D {}
-class DD extends D {
- public field: number = 42;
-}
-
-let c: ~C;
-let d: D;
-
-d = new DD();
-
-c = d; // without the restrictive semantics of optional fields, this assignment would be allowed (but shows compile-time error in N4JS)
-
-console.log(c.field); // prints 42 even though the type is string
-c.field.charAt(0); // exception at runtime: c.field.charAt is not a function</programlisting>
-</para>
-</formalpara>
-<simpara>In the last line of the above example, <literal>c.field</literal> is actually <literal>42</literal> but the type systems claims it is of type <literal>string</literal> and
-thus allows accessing member <literal>charAt</literal> of type <literal>string</literal> which is undefined at runtime the actual value <literal>42</literal>.</simpara>
-<simpara>The next example shows why cases 2 and 3 (i.e. new expressions and instances of final classes) have to be handled in
-a more restrictive manner than case 1 (i.e. object literals).</simpara>
-<formalpara>
-<title>Problem 2 of optional fields</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public field?: string;
-}
-
-class D {}
-
-let c: ~C;
-
-c = new D(); // error: new expression but D is missing setter
-
-c.field = "hello";</programlisting>
-</para>
-</formalpara>
-<simpara>In the previous code, if <literal>c = new D()</literal> were allowed, we would add a new property <literal>field</literal> to the instance of class
-<literal>D</literal> in the last line, which N4JS aims to avoid in general, unless unsafe language features such as dynamic types
-are being employed.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_static-members" role="language-n4js">
-<title>Static Members</title>
-<simpara>Static data fields, field accessors and methods are quite similar to instance members, however they are not members of instances of the type but the type itself.
-They are defined similarly to instance members except that they are specified with the modifier <literal>static</literal>.
-Since they are members of the type, the <literal>this</literal> keyword is not bound to instances of the class, but again to the type itself.
-This is similar as in ECMAScript 6 ([<link linkend="ECMA15a">ECMA15a(p.14.5.15)</link>]).
-Since static members are not instance but type members, it is even possible that a static member has the same name as an instance member.</simpara>
-<simpara>Note that static members are not only allowed in classes but also in interfaces, but there are important differences
-(for example, no inheritance of static members of interfaces, cf. Section <xref linkend="_static-members-of-interfaces"/>).</simpara>
-<requirement xml:id="IDE-65">
-<title>Static member not abstract</title>
-<simpara>
-<anchor xml:id="Req-IDE-65" xreflabel="[Req-IDE-65]"/>
-<emphasis role="strong">Requirement: IDE-65:</emphasis>
-<link linkend="Req-IDE-65">Static member not abstract</link> (ver. 1)</simpara>
- <simpara>
-
-For a static field accessor or method <literal>S</literal>, the following constraint must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>⇔</mo><mo>¬</mo><mi>s</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>Like instance methods, static methods of classes are inherited by subclasses and it is possible to override static methods in subclasses.
-The very same override constraints are valid in this case as well.</simpara>
-<section xml:id="_access-from-and-to-static-members">
-<title>Access From and To Static Members</title>
-<requirement xml:id="IDE-66">
-<title>Accessing Static Members</title>
-<simpara>
-<anchor xml:id="Req-IDE-66" xreflabel="[Req-IDE-66]"/>
-<emphasis role="strong">Requirement: IDE-66:</emphasis>
-<link linkend="Req-IDE-66">Accessing Static Members</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>Let <literal>M</literal> be a static member of class <literal>C</literal>. Except for write-access to
-fields, which will be explained later, you can access <literal>M</literal>
-via:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The class declaration instance, i.e. the classifier or constructor type, <literal>constructor{C}</literal>, i.e. <literal>C.m</literal></simpara>
-</listitem>
-<listitem>
-<simpara>The class declaration instance of a subtype, i.e. the classifier or constructor type, i.e. <literal>D.m</literal>, if <literal>D</literal> is a subclass of <literal>C</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>v.m</literal>, if <literal>v</literal> is a variable of type <literal>C</literal> (i.e. classifier type as defined in <xref linkend="_constructor-and-classifier-type"/>) or a subtype thereof.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>this.m</literal> inside the body of any static method declared in <literal>C</literal> or any sub-class of <literal>C</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Via a type variable <literal>T</literal> which upper bound is a subclassof <literal>C</literal> e.g., <literal>function <T extends C> f(){T.m}</literal></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-67">
-<title>Static Member Access</title>
-<simpara>
-<anchor xml:id="Req-IDE-67" xreflabel="[Req-IDE-67]"/>
-<emphasis role="strong">Requirement: IDE-67:</emphasis>
-<link linkend="Req-IDE-67">Static Member Access</link> (ver. 1)</simpara>
- <simpara>
-
-It is not possible to access instance members from static members.
-This is true in particular for type variables defined by a generic classifier.</simpara>
-</requirement>
-<requirement xml:id="IDE-68">
-<title>Write-access to static data fields and static setter</title>
-<simpara>
-<anchor xml:id="Req-IDE-68" xreflabel="[Req-IDE-68]"/>
-<emphasis role="strong">Requirement: IDE-68:</emphasis>
-<link linkend="Req-IDE-68">Write-access to static data fields and static setter</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For static data fields and static setter <literal>f</literal> the following constraint must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>For every assign expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>∧</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>=</mo><mi>T</mi><mo>.</mo><mi>f</mi><mo>⇒</mo><mi>T</mi><mo>=</mo><mi>f</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>For every writing unary expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>∈</mo><mfenced close="}" open="{"><mrow><mo>+</mo><mo>+</mo></mrow><mrow><mo>-</mo><mo>-</mo></mrow></mfenced><mo>∧</mo><mi>f</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>∧</mo><mi>u</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>=</mo><mi>T</mi><mo>.</mo><mi>f</mi><mo>⇒</mo><mi>T</mi><mo>=</mo><mi>f</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi></math>.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>In the special case of <literal>m</literal> being a static data field, write-access is only possible via the defining type name <literal>C.m</literal>.
-In the list above, only the first line can be used when assigning values to a field. Note that this only applies to fields and set-accessors.<footnote><simpara>The technical reason for this rule is the way properties are stored in JavaScript. Take for an example subclass-write access : <literal role="language-n4js">class C { static f="a";}</literal> with <literal role="language-n4js">class D extends C { }</literal>. Now the data field <literal>f</literal> on <literal>C</literal> can also be queried using <literal>D</literal> (<literal role="language-n4js">var q=D.f;</literal>) but writing (<literal role="language-n4js">D.f="b";</literal>) would introduce a newly created property <literal>f</literal> on class <literal>D</literal>, which differs from the one defined on <literal>C</literal>. It would do this without explicitly overriding the inherited property. Subsequent reads to <literal role="language-n4js">D.f</literal> would route to this ’accidentally’ introduced property. Such a behavior would not be expected and therefore has been disallowed. Note that this write restriction applies to data-fields and to field setters.</simpara></footnote></simpara>
-<simpara>It is even possible to call a static field accessor or method of a class using dynamic polymorphism, as demonstrated in the following example:</simpara>
-<example xml:id="ex:Polymorphism_and_static_methods">
-<title>Static members of classes, inheritance and polymorphism</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- static m(): void { console.log('A#m'); }
-
- static foo(): void { console.log('A#foo'); }
-
- static bar(): void {
- this.foo();
- }
-}
-
-class B extends A {
- @Override
- static foo(): void { console.log('B#foo'); }
-}
-
-A.m(); // will print "A#m"
-B.m(); // will print "A#m" (m is inherited by B)
-
-var t: type{A} = A;
-t.foo(); // will print "A#foo"
-t = B;
-t.foo(); // will print "B#foo"
-
-// using 'this':
-
-A.bar(); // will print "A#foo"
-B.bar(); // will print "B#foo"</programlisting>
-</example>
-<simpara>This is quite different from Java where static methods are not inherited and references to static methods are statically bound at compile time
-depending on the declared type of the receiver (and not its value):</simpara>
-<example>
-<title>Static members in Java</title>
-<programlisting language="java" linenumbering="unnumbered">// !!! JAVA CODE !!!
-public class C {
-
- static void m() { System.out.println("C#m"); }
-
- public static void main(String[] args) {
- final C c = null;
- c.m(); // will print "C#m" (no NullPointerException at runtime)
- }
-}</programlisting>
-</example>
-</section>
-<section xml:id="_generic-static-methods">
-<title>Generic static methods</title>
-<simpara>It is not possible to refer to type variables of a generic class, as these type variables are never bound to any concrete types.
-A static method can, however, be declared generic.
-Generic static methods are defined similarly to generic instance methods.
-Since they cannot refer to type variables of a generic class, the constraint to avoid type variables with equal names (see <xref linkend="Req-IDE-55"/>) does not need to hold for generic static methods.</simpara>
-</section>
-<section xml:id="_static-members-of-interfaces">
-<title>Static Members of Interfaces</title>
-<simpara>Data fields, field accessors and methods of interfaces may be declared
-static. A few restrictions apply:</simpara>
-<requirement xml:id="IDE-69">
-<title>Static Members of Interfaces</title>
-<simpara>
-<anchor xml:id="Req-IDE-69" xreflabel="[Req-IDE-69]"/>
-<emphasis role="strong">Requirement: IDE-69:</emphasis>
-<link linkend="Req-IDE-69">Static Members of Interfaces</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Static members of interfaces may only be accessed directly via the containing interface’s type name
-(this means, of the four ways of accessing static members of classes defined in <xref linkend="Req-IDE-66"/> above, only the first one applies to static members of interfaces).</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal>this</literal> literal may not be used in static methods or field accessors of interfaces and it may not be used in the initializer expression of static fields of interfaces. See <xref linkend="Req-IDE-173"/>.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal>super</literal> literal may not be used in static methods or field accessors of interfaces (in fact, it may not be used in interfaces at all, cf. <xref linkend="Req-IDE-123"/>).</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Note that the <literal>this</literal> type as a return type for methods is only allowed for instance methods and as an argument type only in constructors (structurally typed).
-There is no need to disallow these cases for static interface methods in the constraints above.</simpara>
-<simpara>In general, static members may not be abstract, cf. <xref linkend="Req-IDE-46"/>, which applies here as well.
-Static methods and field accessors of interfaces, therefore, always have to provide a body.</simpara>
-<simpara>Static members of interfaces are much more restricted than those of classes.
-Compare the following example to <xref linkend="_polymorphism-and-static-methods"/> for classes above:</simpara>
-<example>
-<title>Static members of interfaces</title>
-<programlisting language="n4js" linenumbering="unnumbered">interface I {
- static m(): void { console.log('I#m'); }
-}
-
-interface J extends I {}
-
-I.m(); // prints "I#m"
-J.m(); // ERROR! (m is not inherited by J)
-
-var ti: type{I} = I;
-ti.m(); // ERROR! (access to m only allowed directly via type name I)
-ti = J;
-ti.m(); // ERROR! (access to m only allowed directly via type name I)</programlisting>
-</example>
-<simpara>The last line in is the reason why access to static members has to be restricted to direct access via the type name of the containing interfaces.</simpara>
-</section>
-</section>
-<section xml:id="_redefinition-of-members">
-<title>Redefinition of Members</title>
-<simpara>Members defined in classes or interfaces can be redefined by means of being overridden or implemented in subclasses, sub-interfaces, or implementing classes.
-Fields and methods with default implementation defined in interfaces can be consumed by the implementor, but certain restrictions apply.</simpara>
-<requirement xml:id="IDE-70">
-<title>Override Compatible</title>
-<simpara>
-<anchor xml:id="Req-IDE-70" xreflabel="[Req-IDE-70]"/>
-<emphasis role="strong">Requirement: IDE-70:</emphasis>
-<link linkend="Req-IDE-70">Override Compatible</link> (ver. 1)</simpara>
- <simpara>
-
-A member <literal>M</literal> is <emphasis>override compatible</emphasis> to a member <literal>S</literal> if and only if the
-following constraints hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The name and static modifiers are equal:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>S</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>∧</mo><mi>M</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>=</mo><mi>S</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>The metatypes are compatible:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Method</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Method</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>∈</mo><mstyle mathvariant="monospace"><mtext>Field, Getter, Setter</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Getter</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>∈</mo><mstyle mathvariant="monospace"><mtext>Field, Getter</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Setter</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>∈</mo><mstyle mathvariant="monospace"><mtext>Field, Setter</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara>The overridden member must not be declared final:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><mi>S</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Overridden member declared const can only be overridden (redefined) by const members:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mo>⇔</mo><mi>M</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>It is not possible to override a non-final / non-const field or a setter with a final / const field:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close=")" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle><mo>∧</mo><mo>¬</mo><mfenced close=")" open="("><mrow><mi>S</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>∨</mo><mi>S</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi></mrow></mfenced></mrow></mfenced><mo>∨</mo><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Setter</mtext></mstyle><mo>⇒</mo><mo>¬</mo><mfenced close=")" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle><mo>∧</mo><mfenced close=")" open="("><mrow><mi>M</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>∨</mo><mi>M</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi></mrow></mfenced></mrow></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara>It is not possible to override a non-abstract member with an abstract one:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>¬</mo><mi>M</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi><mo>∨</mo><mi>S</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>The types are compatible:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close=")" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>∈</mo><mstyle mathvariant="monospace"><mtext>Method, Getter, Field</mtext></mstyle><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>Setter</mtext></mstyle></mrow></mfenced><mspace width="3.0mm"/><mo>→</mo><mi>Γ</mi><mo>⊢</mo><mi>M</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>S</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close=")" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>∈</mo><mstyle mathvariant="monospace"><mtext>Setter, Field</mtext></mstyle><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>Getter</mtext></mstyle><mo>∧</mo><mo>¬</mo><mi>S</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi></mrow></mfenced><mspace width="3.0mm"/><mo>→</mo><mi>Γ</mi><mo>⊢</mo><mi>S</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>M</mi></math>4</simpara>
-</listitem>
-<listitem>
-<simpara>The access modifier is compatible:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>≥</mo><mi>S</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></math></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>We define a relation <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><mi>M</mi><mi>S</mi></mfenced></math> accordingly.</simpara>
-<simpara>Members overriding or implementing other members must be declared as override.
-If a member does not override another, however, it must not be declared as override.</simpara>
-<requirement xml:id="IDE-71">
-<title>Non-Override Declaration</title>
-<simpara>
-<anchor xml:id="Req-IDE-71" xreflabel="[Req-IDE-71]"/>
-<emphasis role="strong">Requirement: IDE-71:</emphasis>
-<link linkend="Req-IDE-71">Non-Override Declaration</link> (ver. 1)</simpara>
- <simpara>
-
-If and only if a member <literal>M</literal> of a class <literal>C</literal> (extending a class <literal>S</literal> and interfaces <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>i</mi></msub></math>) does not override or implement another member, then it must not be declared as override.
-That is the following constraint must hold:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>¬</mo><mi>M</mi><mo>.</mo><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∧</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∄</mo><msup><mi>M</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>∪</mo><msubsup><mo>⋃</mo><mrow><mi>i</mi><mo>=</mo><mn>1</mn></mrow><mi>n</mi></msubsup><msub><mi>I</mi><mi>i</mi></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>M</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>∧</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>=</mo><mi>M</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∧</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>></mo><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle></math></simpara>
-</requirement>
-<section xml:id="_overriding-of-members" role="language-n4js">
-<title>Overriding of Members</title>
-<simpara>In general, the N4JS platform supports overriding members by redefining them in sub-classes.
-This definition allows for overriding of static methods, but it does not apply to constructors because <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mo>∉</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi></math>.</simpara>
-<requirement xml:id="IDE-72">
-<title>Overriding Members</title>
-<simpara>
-<anchor xml:id="Req-IDE-72" xreflabel="[Req-IDE-72]"/>
-<emphasis role="strong">Requirement: IDE-72:</emphasis>
-<link linkend="Req-IDE-72">Overriding Members</link> (ver. 1)</simpara>
- <simpara>
-
-Given a class <literal>C</literal> and a superclass <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mi>u</mi><mi>p</mi></math>.
-If for an instance or static member <literal>M</literal> defined in <literal>C</literal> a member <literal>S</literal> exists with null
-then we call <literal>M</literal> the overriding member and <literal>S</literal> the overridden member.
-In that case the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>S</literal> must be accessible from <literal>C</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>M</literal> must be override compatible with <literal>S</literal>:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><mi>M</mi><mi>S</mi></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara>If <literal>S</literal> is a field and <literal>M</literal> is an accessor, then an additional accessor <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math> must exists so that <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mo>,</mo><msup><mi>M</mi><mi>'</mi></msup></math> are an accessor pair for <literal>S</literal>:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mrow><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>o</mi><mi>r</mi></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>→</mo><mo>∃</mo><msup><mi>M</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="4.0em"/><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup><mi>S</mi></mfenced><mo>∧</mo><mfenced close="}" open="{"><mrow><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced></mrow><mrow><mi>μ</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup></mfenced></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Getter,Setter</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara><literal>M</literal> must be declared as override:<?asciidoc-br?>
-<literal>M.override</literal></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Remarks:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>An overridden method, getter, or setter may called via <literal>super</literal>.
-Note that this is not possible for fields.</simpara>
-</listitem>
-<listitem>
-<simpara>There is no ’hiding’ of fields as in Java, instead there is field overriding.</simpara>
-</listitem>
-<listitem>
-<simpara>It is not possible to override a field with a consumed getter and an overridden setter, because the getter is not consumed if there exists a field in a superclass.
-In this case, the consuming and extending class needs to define the accessor pair explicitly.
-The same is true for other combination of accessors and fields.</simpara>
-</listitem>
-<listitem>
-<simpara>Overriding a field usually makes only sense if the visibility of the field is to be increased.</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_implementation-of-members">
-<title>Implementation of Members</title>
-<definition>
-<title>Interface and Class Member Sets</title>
-<simpara>
-<anchor xml:id="interface_and_class_member_sets" xreflabel="[interface_and_class_member_sets]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="interface_and_class_member_sets">Interface and Class Member Sets</link></simpara>
-<simpara>
-
-For the following constraints, we define two helper sets <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>C</mi></msub></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>I</mi></msub></math> as follows:</simpara>
-<simpara>Given a <literal>C</literal>, and interface <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>I</mi><mi>n</mi></msub></math>, implemented by <literal>C</literal>, with</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>C</mi></msub><mspace width="3.0mm"/><mo>=</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>∪</mo><mrow><mo>{</mo><mrow><mi>m</mi><mo>∈</mo><mi>C</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>|</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>></mo><mstyle mathvariant="monospace"><mtext>private</mtext></mstyle><mo>}</mo></mrow></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>I</mi></msub><mspace width="3.0mm"/><mo>=</mo><msubsup><mo>⋃</mo><mrow><mi>i</mi><mo>=</mo><mn>1</mn></mrow><mi>n</mi></msubsup><msub><mi>I</mi><mi>i</mi></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math></simpara>
-<simpara>Note that these sets already contain only non-private data fields.</simpara>
-</definition>
-<section xml:id="_member-consumption">
-<title>Member Consumption</title>
-<definition>
-<title>Member Consumption and Implementation</title>
-<simpara>
-<anchor xml:id="member_consumption_and_implementation" xreflabel="[member_consumption_and_implementation]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="member_consumption_and_implementation">Member Consumption and Implementation</link></simpara>
-<simpara>
-
-A member <literal>M</literal> defined in an interface <literal>I</literal> is <emphasis>consumed</emphasis> by an implementor <literal>C</literal>, if it becomes a member of the class, that is, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mo>∈</mo><mi>C</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math>.</simpara>
-<simpara>A member <literal>M</literal> is consumed if there is no member defined in the implementor with the same name and if there is no non-private,
-non-abstract member with that name inherited by the implementor from its superclass. <footnote><simpara>There had been the idea of preventing static members of being consumed. However, this would break the type subtype relation.</simpara></footnote></simpara>
-<simpara>If the implementor defines the member itself, then the member is implemented rather than consumed.</simpara>
-<simpara>The concrete rules are described in the following;</simpara>
-<simpara>It is not always possible to directly consume a member.
-In general, a rather conservative strategy is used: if two implemented interfaces define the same (non-abstract) member then the implementor must redefine the member in order to solve conflicts.
-Even if the two conflicting members have the same types, the implementor must redefine them as we generally assume semantic differences which the consumer has to be aware of.
-Data fields defined in interfaces, in particular, are assumed to be concrete.
-It is not, therefore, possible to consume a field defined in two implemented interfaces.</simpara>
-</definition>
-<requirement xml:id="IDE-73">
-<title>Consumption of Interface Members</title>
-<simpara>
-<anchor xml:id="Req-IDE-73" xreflabel="[Req-IDE-73]"/>
-<emphasis role="strong">Requirement: IDE-73:</emphasis>
-<link linkend="Req-IDE-73">Consumption of Interface Members</link> (ver. 1)</simpara>
- <simpara>
-
-Given a classifier <literal>C</literal> <footnote><simpara><literal>C</literal> could either be a class or an interface.</simpara></footnote>, and interfaces <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>I</mi><mi>n</mi></msub></math> implemented (or extended) by <literal>C</literal>, and sets <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>C</mi></msub></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>I</mi></msub></math> as defined in <xref linkend="interface_and_class_member_sets"/>.
-A non-static member <literal>M</literal> defined in any interface <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>i</mi></msub></math> is merged into the consumer (<literal>C</literal>), if for all other (possible) members <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math> of <literal>C</literal></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><msup><mi>M</mi><mi>'</mi></msup><mo>∈</mo><msub><mi>M</mi><mi>C</mi></msub><mo>∪</mo><msub><mi>M</mi><mi>I</mi></msub><mo>∖</mo><mfenced close="}" open="{"><mi>M</mi></mfenced><mi>:</mi><mi>M</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>∧</mo><mo>¬</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math>
-<simpara>the following constraints hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The other member’s meta type matches the meta type of the merge candiate:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Method</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo><mi>μ</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Method</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>Method</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo><mi>μ</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup></mfenced><mo>∈</mo><mstyle mathvariant="monospace"><mtext>Field, FieldAccessor</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara>The other member is abstract and not owned by the consumer:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mi>μ</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup></mfenced><mo>∨</mo><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="2.0em"/><mo>→</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi><mo>∧</mo><msup><mi>M</mi><mi>'</mi></msup><mo>∉</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>The merge candidate’s access modifier is not less than the modifier of the other member:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mi>μ</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup></mfenced><mo>∨</mo><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="2.0em"/><mo>→</mo><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>≥</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>The merge candidate’s type compatible with the other member:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>∈</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>Method, Getter, Field</mtext></mstyle></mfenced><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>Setter</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo><mi>Γ</mi><mo>⊢</mo><mi>M</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><msup><mi>M</mi><mi>'</mi></msup></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>∈</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>Setter, Field</mtext></mstyle></mfenced><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>Getter</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo><mi>Γ</mi><mo>⊢</mo><msup><mi>M</mi><mi>'</mi></msup><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>M</mi></math></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="_member-implementation" role="language-n4js">
-<title>Member Implementation</title>
-<requirement xml:id="IDE-74">
-<title>Implementation of Interface Members</title>
-<simpara>
-<anchor xml:id="Req-IDE-74" xreflabel="[Req-IDE-74]"/>
-<emphasis role="strong">Requirement: IDE-74:</emphasis>
-<link linkend="Req-IDE-74">Implementation of Interface Members</link> (ver. 1)</simpara>
- <simpara>
-
-For any non-static abstract member <literal>M</literal> defined in an interface <literal>I implemented (or extended) by a classifier `C</literal>, <literal>M</literal> must be accessible
-from <literal>C</literal> and one or two member(s) in <literal>C</literal> must exist which are implementation-compatible with <literal>M</literal>.
-The implementing member(s) must be declared as override if they are directly defined in the consumer.</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>M</literal> must be accessible from <literal>C</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>An implementation-compatible member <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math> must exist in <literal>C</literal>:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>if <literal>M</literal> is not a field:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∃</mo><msup><mi>M</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><msup><mi>M</mi><mi>'</mi></msup><mi>M</mi></mfenced></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mo>∧</mo><mfenced close=")" open="("><mrow><msup><mi>M</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>→</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi></mrow></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>M</literal> is a field, then either an
-implementation-compatible field <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>F</mi><mi>'</mi></msup></math> or accessor pair <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>G</mi><mi>'</mi></msup><mo>,</mo><msup><mi>S</mi><mi>'</mi></msup></math> must exist:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>M</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle><mspace width="3.0mm"/><mo>→</mo></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∃</mo><msup><mi>F</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><msup><mi>F</mi><mi>'</mi></msup><mi>M</mi></mfenced></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mo>∧</mo><mfenced close=")" open="("><mrow><msup><mi>F</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>→</mo><msup><mi>F</mi><mi>'</mi></msup><mo>.</mo><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi></mrow></mfenced></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∨</mo></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∃</mo><msup><mi>G</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>g</mi><mi>e</mi><mi>t</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><msup><mi>S</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>s</mi><mi>e</mi><mi>t</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><msup><mi>G</mi><mi>'</mi></msup><mi>M</mi></mfenced></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mo>∧</mo><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>C</mi><mi>o</mi><mi>m</mi><mi>p</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>b</mi><mi>l</mi><mi>e</mi><mfenced close=")" open="("><msup><mi>S</mi><mi>'</mi></msup><mi>M</mi></mfenced></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mo>∧</mo><mfenced close=")" open="("><mrow><msup><mi>G</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>→</mo><msup><mi>G</mi><mi>'</mi></msup><mo>.</mo><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi></mrow></mfenced></math><?asciidoc-br?>
- <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mo>∧</mo><mfenced close=")" open="("><mrow><msup><mi>S</mi><mi>'</mi></msup><mo>∈</mo><mi>C</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>→</mo><msup><mi>S</mi><mi>'</mi></msup><mo>.</mo><mi>o</mi><mi>v</mi><mi>e</mi><mi>r</mi><mi>r</mi><mi>i</mi><mi>d</mi><mi>e</mi></mrow></mfenced></math></simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Methods defined in interfaces are automatically declared abstract if they do not provide a default implementation.
-This can also be expressed explicitly via adding the <literal>abstract</literal> modifier.
-If a class implementing an abstract interface does not implement a method declared in the interface, the class needs to be declared abstract (cf. <xref linkend="_abstract-classes"/>).</simpara>
-<simpara>Consequences for method implementation:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>It may be require the implementor to explicitly define a method in order to solve type conflicts produced by methods of different interfaces with same name but different signatures.</simpara>
-</listitem>
-<listitem>
-<simpara>Methods in an implementor cannot decrease the accessibility of methods from implemented interfaces, that is</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∀</mo><mi>M</mi><mo>∈</mo><mi>C</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mo>,</mo><msup><mi>M</mi><mi>'</mi></msup><mo>∈</mo><msub><mi>I</mi><mi>i</mi></msub><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mfenced close=")" open="("><mrow><mi>i</mi><mo>=</mo><mn>1</mn><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mi>n</mi></mrow></mfenced><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="2.0em"/><mi>M</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>→</mo><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>≠</mo><mi>p</mi><mi>r</mi><mi>i</mi><mi>v</mi><mi>a</mi><mi>t</mi><mi>e</mi><mo>⇒</mo><mi>M</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>≥</mo><msup><mi>M</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Methods in the implementor must be a supertype <footnote><simpara>As defined in <xref linkend="_function-type"/> for function types.</simpara></footnote> of methods from implemented interfaces.
-That is to say the implemented methods are override-compatible.</simpara>
-</listitem>
-<listitem>
-<simpara>There may be several methods <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>M</mi><mi>n</mi></msub></math> defined in different implemented interfaces and a single owned method <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math> in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>C</mi></msub></math>.
-In this case, the above constraints must hold for <emphasis>all</emphasis> methods. In particular, <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math>’s signature must conform to all conflicting methods’ signatures.
-This is possible by using union types for the arguments and an intersection type as return type.
-Such a method <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math> is said to <emphasis>resolve</emphasis> the conflict between the implemented (and also inherited) methods.</simpara>
-</listitem>
-<listitem>
-<simpara>Since abstracts methods may become part of the implementor methods, the implementor must either define these methods or it must be declared abstract itself.
-Since interfaces are abstract by default, responsibility for implementing abstract methods is passed on to any implementor of interfaces.</simpara>
-</listitem>
-<listitem>
-<simpara>If two implemented interfaces provide (non-abstract) members with the same name, they are not automatically consumed by the implementor even if the types would be similar.
-In these cases, the implementor has to redefine the members in order to be aware of possible semantic differences.</simpara>
-</listitem>
-</orderedlist>
-<simpara>There is currently no separate annotation to indicate that methods are implemented or overridden in order to solve conflicts.
-We always use the <literal>@Override</literal> annotation.</simpara>
-<example>
-<title>Method Consumption</title>
-<simpara><xref linkend="tab:methodConsumption"/> shows simple examples of above rules.
-Assuming that <literal>class C</literal> extends super <literal>class S</literal> and implements interface <literal>I1</literal> and <literal>I2</literal>:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C extends S implements I1, I2 {...}</programlisting>
-</example>
-<simpara>The columns describe different scenarios in which a method (with same name) is defined in different classifiers.
-We assume that the defined methods are always non-abstract (i.e. have default implementations), non-private and have the same signature.
-The last row shows which method will be actually used in class <literal>C</literal>.
-If the method is defined in class <literal>C</literal>, and if this method is printed bold, then this means that the method is required to be defined in <literal>C</literal> in order to solve conflicts.</simpara>
-<table xml:id="tab:methodConsumption" frame="all" rowsep="1" colsep="1">
-<title>Consumption of methods</title>
-<tgroup cols="7">
-<colspec colname="col_1" colwidth="25*"/>
-<colspec colname="col_2" colwidth="12.5*"/>
-<colspec colname="col_3" colwidth="12.5*"/>
-<colspec colname="col_4" colwidth="12.5*"/>
-<colspec colname="col_5" colwidth="12.5*"/>
-<colspec colname="col_6" colwidth="12.5*"/>
-<colspec colname="col_7" colwidth="12.5*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Interface <literal>I1</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I1</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I1</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I1</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I1</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I1</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I1</subscript></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Interface <literal>I2</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I2</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I2</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I2</subscript></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">class <literal>S</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>S</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>S</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>S</subscript></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">class <literal>C</literal></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>C</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">M<subscript>C</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>C</subscript></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong"><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∈</mo><mi>C</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi></math></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>I1</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>C</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>C</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>S</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>S</subscript></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis>M<subscript>C</subscript></emphasis></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<variablelist xml:id="consuming-field-initializers">
-<varlistentry>
-<term>Consuming Field Initializers </term>
-<listitem>
-<simpara>Aside from the fields themselves, an implementor <emphasis>always</emphasis> consumes the field initialization if the field is consumed – this is how the consumption is noticed at runtime.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<example>
-<title>Field and Field Initializer Consumption</title>
-<programlisting language="n4js" linenumbering="unnumbered">/* XPECT output ~~~
-<==
-stdout:
-s: C , t: D ,u: I1 ,v: I2
-stderr:
-==>
-~~~ */
-
-interface I0 {
- v: string = "I0";
-}
-
-interface I1 {
- s: string = "I1";
- t: string = "I1";
- u: string = "I1";
-}
-
-interface I2 extends I1, I0 {
- @Override
- t: string = "I2";
- @Override
- v: string = "I2";
-}
-
-class C {
- s: string = "C";
-}
-
-class D extends C implements I1, I2 {
- @Override
- t: string = "D";
-}
-
-var d = new D();
-
-console.log(
- "s:", d.s, ", t:", d.t, ",u:", d.u, ",v:", d.v
-)</programlisting>
-<simpara>We expect the following output (for each field):</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>d.s = "C"</literal> : <literal>s</literal>: is inherited from <literal>C</literal>, so it is not consumed from <literal>I1</literal> (or <literal>I2</literal>).
-Consequently, the initializer of <literal>s</literal> in <literal>C</literal> is used.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>d.t = "D"</literal>: <literal>t</literal> is defined in <literal>D</literal>, solving a conflict stemming from the definition of <literal>t</literal> in <literal>I1</literal> and <literal>I2</literal>. Thus, the initializer of <literal>t</literal> in <literal>D</literal> is used.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>d.u = "I1"</literal> : <literal>u</literal> is only defined in <literal>I1</literal>, thus the initializer defined in <literal>I1</literal> is used.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>d.v = "I2"</literal> : <literal>v</literal> is overridden in <literal>I2</literal>, so is the field initializer. This is why <literal>d.v</literal> must be assigned to <literal>I2</literal> and not <literal>I0</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</example>
-</section>
-</section>
-</section>
-</section>
-<section xml:id="_structural-typing">
-<title>Structural Typing</title>
-<simpara>In general, N4JS uses nominal typing.
-This is to say that a duck is a duck only if it is declared to be a duck.
-In particular when working with external APIs, it is more convenient to use structural or duck typing.
-That is, a thing that can swim and quacks like a duck, is a duck.</simpara>
-<simpara role="language-n4js">Interfaces or classes can be used for this purpose with a <emphasis>typing strategy modifier</emphasis>.
-Given a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>, the simple <literal>~</literal> (tilde) can be added to its declaration (on definition-site) or in a reference (on use-site) to indicate that the type system should use structural typing
-rather than nominal typing.<footnote><simpara>This kind of typing is used by TypeScript only. By defining a structural typed classifier or reference, it basically behaves as it would behave – without that modifier – in TypeScript.</simpara></footnote>
-This means that some other type must provide the same members as type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> to be deemed a structural subtype.
-However, the operator cannot be used anymore with the type or reference as this operator relies on the declaration information (or at least the closest thing available at runtime).
-In this case, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> is, therefore, always a structural subtype of <emphasis>~T</emphasis>.</simpara>
-<simpara role="language-n4js">Sometimes it is convenient to refer only to the fields of a classifier, for example when the initial field values are to be provided in a variable passed to the constructor.
-In that case, the type can be modified with <literal>~~</literal> (two tildes). This is only possible on use-site, i.e. on type references.
-Furthermore, only on the use-site, it is possible to consider only either readable or writable or fields by using the read-only <literal>~r~</literal> or write-only <literal>~w~</literal> structural field typing.
-For initialization blocks, it is even possible to use structural initializer field typing via the <literal>~i~</literal> operator.</simpara>
-<section xml:id="_syntax-7" role="language-n4js">
-<title>Syntax</title>
-<simpara>Structural typing is specified using the typing strategy modifier. There
-are two modifiers defined; one for definition-site and one for use-site
-structural typing.</simpara>
-<formalpara xml:id="lst:Structural_Type_Operator_and_References">
-<title>Structural Type Operator and References</title>
-<para>
-<programlisting language="xtext" linenumbering="unnumbered">TypingStrategyUseSiteOperator returns TypingStrategy:
- '~' ('~' | STRUCTMODSUFFIX)?;
-
-TypingStrategyDefSiteOperator returns TypingStrategy:
- '~';
-
-terminal STRUCTMODSUFFIX:
- ('r' | 'i' | 'w') '~'
-;
-
-ParameterizedTypeRefStructural returns ParameterizedTypeRefStructural:
- definedTypingStrategy=TypingStrategyUseSiteOperator
- declaredType=[Type|TypeReferenceName]
- (=> '<' typeArgs+=TypeArgument (',' typeArgs+=TypeArgument)* '>')?
- (=> 'with' '{' astStructuralMembers+=TStructMember* '}')?
-;
-
-ThisTypeRefStructural returns ThisTypeRefStructural:
- definedTypingStrategy=TypingStrategyUseSiteOperator
- 'this'
- ('with' '{' astStructuralMembers+=TStructMember* '}')?
-;</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="_definition-site-structural-typing" role="language-n4js">
-<title>Definition Site Structural Typing</title>
-<simpara>An interface or class can be defined to be used with structural typing by adding the structural modifier to its definition (or, in case of external classes, to the declaration).
-This changes the default type system strategy from nominal to structural typing for that type.
-That means that all types with the same members as the specified type are subtypes of that type, except for subtypes of <literal>N4Object</literal>.
-In the latter case, programmers are enforced to nominal declare the type relation.</simpara>
-<simpara>If a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> is declared as structural at its definition, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math> is true.</simpara>
-<requirement xml:id="IDE-75">
-<title>Definition Site Structural Typing</title>
-<simpara>
-<anchor xml:id="Req-IDE-75" xreflabel="[Req-IDE-75]"/>
-<emphasis role="strong">Requirement: IDE-75:</emphasis>
-<link linkend="Req-IDE-75">Definition Site Structural Typing</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The structurally defined type cannot be used on the right hand side of the <literal>instanceof</literal> operator:
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>x</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>instanceof</mtext></mstyle><mi> </mi><mi>T</mi><mo>⇒</mo><mo>¬</mo><mi>T</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>A type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> is a subtype of a structurally defined type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> either</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>if it is not a subtype of <literal>N4Object</literal> <footnote><simpara>We enforce programmers of N4JS to use nominal typing, therefore, it is not possible to bypass that principle by declaring a type as structural for normally defined classes (except those explicitly derived from <literal>N4Object</literal>).</simpara></footnote>
-but it contains all public, non-static members of that type</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle></mfenced><mspace width="3.0em"/><mi>T</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>}</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>T</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>,</mo><mo>¬</mo><mi>m</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>,</mo><mi>m</mi><mo>≠</mo><mi>T</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mi>:</mi><mi>}</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0em"/><mo>∃</mo><msup><mi>m</mi><mi>'</mi></msup><mo>∈</mo><mi>X</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi><mi>}</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>∧</mo><mo>¬</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mi>}</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><msup><mi>m</mi><mi>'</mi></msup><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>m</mi><mi>}</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mspace width="2.0em"/><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><mi>m</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Field</mtext></mstyle><mo>⇒</mo><mi>Γ</mi><mo>⊢</mo><mi>m</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><msup><mi>m</mi><mi>'</mi></msup></mrow><mrow><mspace width="13.0em"/><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi><mspace width="13.0em"/></mrow></mfrac></math><?asciidoc-br?>
-or</simpara>
-</listitem>
-<listitem>
-<simpara>if it is a subtype of <literal>N4Object</literal> which explicitly extends or implements the
-structurally defined type.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle></mfenced><mspace width="3.0mm"/><mi>T</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mspace width="3.0mm"/><mrow><mi>T</mi><mo>∈</mo><mi>X</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><msup><mi>s</mi><mo>*</mo></msup></mrow></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>T</mi></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>A structurally defined type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> is implicitly derived
-from <literal>Object</literal> if no other type is specified. In particular, a structurally
-defined type must not be inherited from</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>T</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>Object</mtext></mstyle></mrow></mfrac></math></simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mo>⇒</mo><mi>Γ</mi><mo>⊢</mo><mi>T</mi><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle><mo>∧</mo><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle><mo>∉</mo><mi>T</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><msup><mi>s</mi><mo>*</mo></msup></math></simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</requirement>
-<example>
-<title>Declaration Site Structural Typing</title>
-<simpara>The following snippet demonstrates the effect of definition-site structural types by comparing them to
-nominal declared types: <anchor xml:id="ex:declaration-site-structural-typing" xreflabel="[ex:declaration-site-structural-typing]"/></simpara>
-<formalpara>
-<title>Declaration Site Structural Typing</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">interface ~Tilde { x; y; }
-interface Nominal { x; y; }
-class C { public x; public y;}
-class D extends C implements Tilde { }
-
-function f(p: Tilde) {}
-function g(p: Nominal) {}
-
-f(new C()); // error: nominal typing, C does not implement ~Tilde
-f(new D()); // ok, D is a nominal subtype (as it implements Tilde)
-f({x:10,y:10}); // ok: Tilde is used with structural typing for non-N4-classifiers</programlisting>
-</para>
-</formalpara>
-<simpara>Definition site structural typing may lead to unexpected results. For
-example;</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C{}
-class ~E extends C{}</programlisting>
-<simpara>It may be unexpected, but <literal>E</literal> is not a subtype of <literal>C</literal>, i.e.
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>C</mi></math>! E.g., <literal>instanceof</literal> won’t work with <literal>E</literal>, while it works
-with <literal>C</literal>!</simpara>
-</example>
-</section>
-<section xml:id="_use-site-structural-typing" role="language-n4js">
-<title>Use-Site Structural Typing</title>
-<simpara>Use-site structural typing offers several typing strategy modifiers to define the accessability of public properties of classes and interfaces.
-They can be used e.g. on variable declarations like this: <literal>var c : ~C</literal>.
-The table <xref linkend="tab:available-fields-of-structural-types"/> shows which properties of structural types can be accessed in the different type strategies.
-For example, when using the write-only structural strategy (i.e. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>w</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math>), only the writeable fields, can be accessed for writing.
-In the table, the term field to both, public datafields and accessors of type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math>.
-Non-public properties are never accessable in use-site structural types.
-In any field-structural type, methods of the referenced nominal type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> are not available.
-The initializer structural typing provides readable fields for every writeable field of the references type.</simpara>
-<table xml:id="tab:available-fields-of-structural-types" frame="all" rowsep="1" colsep="1">
-<title>Available Fields of Structural Types</title>
-<tgroup cols="6">
-<colspec colname="col_1" colwidth="16.6666*"/>
-<colspec colname="col_2" colwidth="16.6666*"/>
-<colspec colname="col_3" colwidth="16.6666*"/>
-<colspec colname="col_4" colwidth="16.6666*"/>
-<colspec colname="col_5" colwidth="16.6666*"/>
-<colspec colname="col_6" colwidth="16.667*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Property of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math></entry>
-<entry align="center" valign="top"><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math></entry>
-<entry align="center" valign="top"><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math></entry>
-<entry align="center" valign="top"><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>r</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math></entry>
-<entry align="center" valign="top"><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>w</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math></entry>
-<entry align="center" valign="top"><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>i</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math></entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara>public method</simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>∅</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>∅</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>∅</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>∅</mi></math></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>public writable field</simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>∅</mi></math></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>∅</mi></math></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>public readable field</simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>∅</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara>writable fields</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara>Multiple structural typing strategies can be nested when there are multiple use sites, like in the example <xref linkend="ex:nested-structural-typing-strategies"/> below at the locations ST1 and ST2.
-In the example, the datafield <literal>a.field</literal> has the nested structural type <literal>~r~ ~i~ A</literal> and thus the datafield <literal>a.field.df</literal> is readable.
-Nested structural types are evaluated on the fly when doing subtype checks.</simpara>
-<example xml:id="ex:nested-structural-typing-strategies">
-<title>Nested Structural Typing Strategies</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- public df : string;
-}
-interface I<T> {
- public field : ~r~T; // ST1
-}
-var a : ~i~A; // ST2</programlisting>
-</example>
-<simpara>The following example demonstrates the effect of the structural type modifiers:</simpara>
-<example>
-<title>Effect of structural type modifiers on use-site</title>
-<simpara>Let’s assume the type defined on the left.
-The following <emphasis>pseudo</emphasis> code snippets explicitly list the type with its members virtually created by a structural modifier.
-Note that this is pseudo code, as there are no real or virtual types created.
-Instead, only the subtype relation is defined accordingly:</simpara>
-<simpara>Effect of structural type modifiers on use-site</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="center" valign="top" namest="col_1" nameend="col_3"><simpara><emphasis role="strong">Effect of structural type modifiers on use-site</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var c:C
-
-class C {
- private x;
- public y;
- public f()
- private g()
- public get z():Z
- public set z(z:Z)
-}
-interface I {
- a;
- func();
-}</programlisting></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var cstructural:~C
-
-class cstructural {
-
- public y;
- public f()
-
- public get z():Z
- public set z(z:Z)
-}
-interface ~I {
- a;
- func();
-}</programlisting></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var cfields:~~C
-
-class cfields {
-
- public y;
-
-
- public get z():Z
- public set z(z:Z)
-}
-interface ~~I {
- a;
-
-}</programlisting></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Type</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Structural Type</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Structural Field Type</emphasis></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var crofields:~r~C
-
-class crofields {
-
- public get y():Y
-
-
- public get z():Z
-
-}
-interface ~r~I {
- public get a():A
-
-}</programlisting></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var cwofields:~w~C
-
-class cwofields {
-
- public set y(y:Y)
-
-
-
- public set z(z:Z)
-}
-interface ~w~I {
- public set a(a:A)
-
-}</programlisting></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">var cinitfields:~i~C
-
-class cinitfields {
-
- public get y():Y
-
-
- public get z():Z
-
-}
-interface ~i~I {
- public get a():A
-
-}</programlisting></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Structural Read-only Field Type</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Structural Write-only Field Type</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Structural Initializer Field Type</emphasis></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><?asciidoc-pagebreak?></simpara>
-<simpara>Note that even if a type is defined without the structural modifier, it is not possible to use <literal>instanceof</literal> for variables declared as structural, as shown in the next example:</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">class C {..}
-interface I {..}
-
-foo(c: C, i: I) {
- c instanceof C; // ok
- c instanceof I; // ok
-}</programlisting></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">class C {..}
-interface I {..}
-
-foo(c: ~C, i: ~I) {
- c instanceof C; // error
- c instanceof I; // error
-}</programlisting></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">class C {..}
-interface I {..}
-
-foo(c: ~~C, i: ~~I) {
- c instanceof C; // error
- C instanceof I; // error
-}</programlisting></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Type</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Structural Type</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Structural Field Type</emphasis></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<itemizedlist>
-<listitem>
-<simpara>If a type is referenced with the structural type modifier <literal>~</literal> , the property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math> is true.</simpara>
-</listitem>
-<listitem>
-<simpara>If a type is referenced with the structural field type modifier <literal>~~</literal>, the property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math> is true.</simpara>
-</listitem>
-<listitem>
-<simpara>If a type is referenced with the structural read-only field type modifier <literal>~r~</literal>, the property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>R</mi><mi>e</mi><mi>a</mi><mi>d</mi><mi>O</mi><mi>n</mi><mi>l</mi><mi>y</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math> is true.</simpara>
-</listitem>
-<listitem>
-<simpara>If a type is referenced with the structural write-only field type modifier <literal>~w~</literal>, then the property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>W</mi><mi>r</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>O</mi><mi>n</mi><mi>l</mi><mi>y</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math> is true.</simpara>
-</listitem>
-<listitem>
-<simpara>If a type is referenced with the structural initializer field type modifier <literal>~i~</literal>, then the property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>I</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math> is true.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>We call the following:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> the (nominal) type T,</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math> the structural version of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>,</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math> the structural field version of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>,</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>r</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math> the structural read-only field,</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>w</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math> the structural write-only field and</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>i</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math> the structural initializer field version of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>.</simpara>
-</listitem>
-</itemizedlist>
-</example>
-<requirement xml:id="IDE-76">
-<title>Use-Site Structural Typing</title>
-<simpara>
-<anchor xml:id="Req-IDE-76" xreflabel="[Req-IDE-76]"/>
-<emphasis role="strong">Requirement: IDE-76:</emphasis>
-<link linkend="Req-IDE-76">Use-Site Structural Typing</link> (ver. 1)</simpara>
- <simpara>
-
-1. The structural version of a type is a supertype of the nominal type:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>:</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>
-2. The structural field version of a type is a supertype of the structural type:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>:</mi><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>
-3. The structural read-only field version of a type is a supertype of the structural field type:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>:</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>r</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>
-4. The structural write-only field version of a type is a supertype of the structural field type:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>:</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>w</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>
-5. The structural (field) version of a type cannot be used on the right hand side of the <literal>instanceof</literal> operator:</simpara>
-<simpara>+</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>x</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>instanceof</mtext></mstyle><mi> </mi><mi>E</mi><mo>⇒</mo><mi>Γ</mi><mo>⊢</mo><mi>E</mi><mi>:</mi><mi>T</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mo>⇒</mo><mo>¬</mo><mrow><mo>(</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="6.0em"/><mo>∨</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="6.0em"/><mo>∨</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>R</mi><mi>e</mi><mi>a</mi><mi>d</mi><mi>O</mi><mi>n</mi><mi>l</mi><mi>y</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="6.0em"/><mo>∨</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>W</mi><mi>r</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>O</mi><mi>n</mi><mi>l</mi><mi>y</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mspace width="3.0mm"/><mspace width="6.0em"/><mo>∨</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>I</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mo>)</mo></mrow></math></simpara>
-<simpara>+
-That is, the following code will always issue an error: <literal>x instanceof ~T</literal> <footnote><simpara>Since this is already prevented by the parser (the tilde is interpreted as an unary operator), error messages are likely to look a little strange.</simpara></footnote>.
-6. A type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> is a subtype of a structural version of a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>, if it contains all public, non-static members of the type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>: <footnote><simpara>Note that due to this relaxed definition (compared with definition-site structural types) it is possible to pass an <literal>N4Object</literal> instance to a function of method with a declared structural type parameter.</simpara></footnote></simpara>
-<simpara>+</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>T</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>m</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>∉</mo><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle><mo>,</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>,</mo><mo>¬</mo><mi>m</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>,</mo><mi>m</mi><mo>≠</mo><mi>T</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0em"/><mo>∃</mo><msup><mi>m</mi><mi>'</mi></msup><mo>∈</mo><mi>X</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>∧</mo><mo>¬</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mspace width="2.0em"/><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><msup><mi>m</mi><mi>'</mi></msup><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>m</mi></mrow><mrow><mspace width="13.0em"/><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="13.0em"/></mrow></mfrac></math><?asciidoc-br?>
-7. A type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> is a subtype of a structural field version of a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>, if it contains all public, non-static fields of the type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>.<?asciidoc-br?>
-Special cases regarding optional fields are described in <link linkend="optional-fields">Optional Fields</link>.</simpara>
-<simpara>+</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>T</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mo>,</mo><mi>m</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>∉</mo><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle><mo>,</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>,</mo><mo>¬</mo><mi>m</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0em"/><mo>∨</mo><mi> </mi><mo>∃</mo><msup><mi>m</mi><mi>'</mi></msup><mo>∈</mo><mi>X</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0em"/><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>∧</mo><mo>¬</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0em"/><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><msup><mi>m</mi><mi>'</mi></msup><mi>:</mi><msub><mi>T</mi><mi>m</mi></msub><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><mi>m</mi><mi>:</mi><msub><mi>T</mi><msup><mi>m</mi><mi>'</mi></msup></msub><mo>∧</mo><msub><mi>T</mi><mi>m</mi></msub><mo>=</mo><msub><mi>T</mi><msup><mi>m</mi><mi>'</mi></msup></msub><mi>}</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mspace width="3.0em"/><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi><mo>≥</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi></mrow><mrow><mspace width="13.0em"/><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="13.0em"/></mrow></mfrac></math></simpara>
-<simpara>+
-8. A type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> is a subtype of a structural read-only field version of a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>r</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>, if it contains all public and non-static readable fields of the type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>.
-Special cases regarding optional fields are described in <link linkend="optional-fields">Optional Fields</link>.</simpara>
-<simpara>+</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>T</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mo>∪</mo><mi>T</mi><mo>.</mo><mi>g</mi><mi>e</mi><mi>t</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>m</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>∉</mo><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle><mo>,</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>,</mo><mo>¬</mo><mi>m</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0em"/><mo>∨</mo><mi> </mi><mo>∃</mo><msup><mi>m</mi><mi>'</mi></msup><mo>∈</mo><mi>X</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mo>∪</mo><mi>X</mi><mo>.</mo><mi>g</mi><mi>e</mi><mi>t</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0em"/><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>∧</mo><mo>¬</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0em"/><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><msup><mi>m</mi><mi>'</mi></msup><mi>:</mi><msub><mi>T</mi><mi>m</mi></msub><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><mi>m</mi><mi>:</mi><msub><mi>T</mi><msup><mi>m</mi><mi>'</mi></msup></msub><mo>∧</mo><msub><mi>T</mi><mi>m</mi></msub><mo>=</mo><msub><mi>T</mi><msup><mi>m</mi><mi>'</mi></msup></msub></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mspace width="3.0em"/><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi><mo>≥</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi></mrow><mrow><mspace width="13.0em"/><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>~</mi><mstyle mathvariant="monospace"><mtext>r</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="13.0em"/></mrow></mfrac></math></simpara>
-<simpara>+
-9. A type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> is a subtype of a structural write-only field version of a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>w</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>, if it contains all public and non-static writable fields of the type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>. Special cases regarding optional fields are described in <link linkend="optional-fields">Optional Fields</link>.</simpara>
-<simpara>+</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>T</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mo>∪</mo><mi>T</mi><mo>.</mo><mi>s</mi><mi>e</mi><mi>t</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>m</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>∉</mo><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle><mo>,</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>,</mo><mo>¬</mo><mi>m</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>,</mo><mo>¬</mo><mi>m</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0em"/><mo>∨</mo><mi> </mi><mo>∃</mo><msup><mi>m</mi><mi>'</mi></msup><mo>∈</mo><mi>X</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mo>∪</mo><mi>X</mi><mo>.</mo><mi>s</mi><mi>e</mi><mi>t</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0em"/><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>∧</mo><mo>¬</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0em"/><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><msup><mi>m</mi><mi>'</mi></msup><mi>:</mi><msub><mi>T</mi><mi>m</mi></msub><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><mi>m</mi><mi>:</mi><msub><mi>T</mi><msup><mi>m</mi><mi>'</mi></msup></msub><mo>∧</mo><msub><mi>T</mi><mi>m</mi></msub><mo>=</mo><msub><mi>T</mi><msup><mi>m</mi><mi>'</mi></msup></msub></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mspace width="3.0em"/><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi><mo>≥</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi></mrow><mrow><mspace width="13.0em"/><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>~</mi><mstyle mathvariant="monospace"><mtext>w</mtext></mstyle><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="13.0em"/></mrow></mfrac></math></simpara>
-<simpara>+
-10. A type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> is a subtype of a structural field version of a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>this</mtext></mstyle></math>, if it contains all public, non-static fields,
-either defined via data fields or field get accessors, of the inferred type of <literal>this</literal>.
-Special cases regarding optional fields are described in <link linkend="optional-fields">Optional Fields</link>.</simpara>
-<simpara>+</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>⊢</mo><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi><mi>:</mi><mi>T</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>T</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mo>∪</mo><mi>T</mi><mo>.</mo><mi>s</mi><mi>e</mi><mi>t</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mo>,</mo><mi>m</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>∉</mo><mstyle mathvariant="monospace"><mtext>N4Object</mtext></mstyle><mo>,</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>,</mo><mo>¬</mo><mi>m</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∨</mo><mi>m</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0em"/><mo>∨</mo><mi> </mi><mo>∃</mo><msup><mi>m</mi><mi>'</mi></msup><mo>∈</mo><mi>X</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>s</mi><mo>∪</mo><mi>X</mi><mo>.</mo><mi>g</mi><mi>e</mi><mi>t</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0em"/><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle><mo>∧</mo><mo>¬</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mspace width="3.0em"/><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><msup><mi>m</mi><mi>'</mi></msup><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>m</mi><mo>∧</mo><msup><mi>m</mi><mi>'</mi></msup><mo>.</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi><mo>≥</mo><mi>m</mi><mo>.</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>a</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi></mrow><mrow><mspace width="13.0em"/><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>t</mtext></mstyle><mi>h</mi><mi>i</mi><mi>s</mi><mspace width="13.0em"/></mrow></mfrac></math></simpara>
-<simpara>+
-11. A structural field type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math> is a subtype of a structural type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math>, if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math> only contains fields (except methods inherited from <literal>Object</literal>) and if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></math>.</simpara>
-<simpara>+</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>X</mi><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mo>∖</mo><mstyle mathvariant="monospace"><mtext>Object</mtext></mstyle><mo>.</mo><mi>m</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mo>=</mo><mi>∅</mi><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>~</mi><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>~</mi><mstyle mathvariant="monospace"><mtext>X</mtext></mstyle></mrow></mfrac></math>
-<simpara>+
-12. Use-site structural typing cannot be used for declaring supertypes of classes or interfaces.
-That is to say that structural types cannot be used after <literal>extends</literal>, <literal>implements</literal> or <literal>with</literal> in type declarations <footnote><simpara>This is already constrained by the grammar.</simpara></footnote>.</simpara>
-</requirement>
-<simpara>Note that all members of <literal>N4Object</literal> are excluded.
-This implies that extended reflective features (cf. <xref linkend="_reflection-meta-information"/> ) are not available in the context of structural typing.
-The <literal>instanceof</literal> operator is still working as described in <xref linkend="_relational-expression"/>, in that it can be used to check the type of an instance.</simpara>
-<simpara>If a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> is a (nominal) subtype of T, it is, of course, also a subtype of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></math>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>~</mi><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle></mrow></mfrac></math>
-<simpara>This is only a shortcut for the type inference defined above.</simpara>
-<requirement xml:id="IDE-77">
-<title>Definition and Use-Site Precedence</title>
-<simpara>
-<anchor xml:id="Req-IDE-77" xreflabel="[Req-IDE-77]"/>
-<emphasis role="strong">Requirement: IDE-77:</emphasis>
-<link linkend="Req-IDE-77">Definition and Use-Site Precedence</link> (ver. 1)</simpara>
- <simpara>
-
-If a type is structurally typed on both definition and use-site, the rules for
-use-site structural typing (<xref linkend="Req-IDE-76"/>) are
-applied.</simpara>
-<example>
-<title>Use-Site Structural Typing</title>
-<simpara>The following example demonstrates the effect of the structural (field) modifier, used in this case for function parameters.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface I { public x: number; public foo()};
-class C { public x: number; public foo() {}};
-
-function n(p: I) {}
-function f(p: ~I) {}
-function g(p: ~~I) {}
-
-n(new C()); // error: nominal typing, C does not implement I
-f(new C()); // ok: C is a (structural) subtype of ~I
-f({x:10}); // error, the object literal does not provide function foo()
-g({x:10}); // ok: object literal provides all fields of I</programlisting>
-</example>
-<example>
-<title>Structural types variable and instanceof operator</title>
-<simpara>It is possible to use a variable typed with a structural version of a type on the left hand side of the <literal>instanceof</literal> operator, as demonstrated in this example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public x;
- public betterX() { return this.x||1;}
-}
-
-function f(p: ~~C) {
- if (p instanceof C) {
- console.log((p as C).betterX);
- } else {
- console.log(p.x||1);
- }
-}</programlisting>
-</example>
-<simpara>The following table describes the member availability of <literal>X</literal> in various
-typing scenarios. Such as <literal>~~X</literal>, <literal>~r~X</literal>, <literal>~w~X</literal>, <literal>~i~X</literal>.</simpara>
-<table role="language-n4js" frame="all" rowsep="1" colsep="1">
-<title>Member Availability in various Typing Scenarios</title>
-<tgroup cols="5">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="16.6666*"/>
-<colspec colname="col_3" colwidth="16.6666*"/>
-<colspec colname="col_4" colwidth="16.6666*"/>
-<colspec colname="col_5" colwidth="16.6669*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Member of type <emphasis>X</emphasis></entry>
-<entry align="center" valign="top"><literal>~~X</literal></entry>
-<entry align="center" valign="top"><literal>~r~X</literal></entry>
-<entry align="center" valign="top"><literal>~w~X</literal></entry>
-<entry align="center" valign="top"><literal>~i~X</literal></entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><literal>private m0;</literal></simpara></entry>
-<entry align="center" valign="top"><simpara> — </simpara></entry>
-<entry align="center" valign="top"><simpara> — </simpara></entry>
-<entry align="center" valign="top"><simpara> — </simpara></entry>
-<entry align="center" valign="top"><simpara> — </simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public set m1(m) { }</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>write</simpara></entry>
-<entry align="center" valign="top"><simpara> — </simpara></entry>
-<entry align="center" valign="top"><simpara>write</simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public get m2() {…​}</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-<entry align="center" valign="top"><simpara> — </simpara></entry>
-<entry align="center" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public m3;</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>read/write</simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-<entry align="center" valign="top"><simpara>write</simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public m4 = 'init.m4';</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>read/write</simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-<entry align="center" valign="top"><simpara>write</simpara></entry>
-<entry align="center" valign="top"><simpara>read <emphasis>?</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public m5: any?;</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>read<emphasis>?</emphasis>/write</simpara></entry>
-<entry align="center" valign="top"><simpara>read<emphasis>?</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>write</simpara></entry>
-<entry align="center" valign="top"><simpara>read<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>?</mi></math></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Final public m6 = 'init.m6';</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Final public m7;</literal></simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"><simpara>read</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public get m8() {…​}</literal></simpara></entry>
-<entry align="center" valign="middle" morerows="1"><simpara>read/write</simpara></entry>
-<entry align="center" valign="middle" morerows="1"><simpara>read</simpara></entry>
-<entry align="center" valign="middle" morerows="1"><simpara>write</simpara></entry>
-<entry align="center" valign="middle" morerows="1"><simpara>read</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>public set m8(m) { }</literal></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-</requirement>
-</section>
-<section xml:id="structural-readWriteInit-field-typing" role="language-n4js">
-<title>Structural Read-only, Write-only and Initializer Field Typing</title>
-<simpara>Structural read-only, write-only and initializer field typings are extensions of structural field typing.
-Everything that is defined for the field structural typing must comply with these extension field typings.
-For the read-only type, readable fields (mutable and <literal>@Final</literal> ones) and setters are considered, for the write-only type; only the setters and mutable fields are considered.
-Due to the hybrid nature of the initializer type it can act two different ways.
-To be more precise, a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> (structural initializer field type) is a supertype of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Y</mi></math> (structural initializer field type) if for each public, non-static, non-optional writable field (mutable data field of setter) of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math>, there is a corresponding, public, non-static readable field of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Y</mi></math>.
-All public member fields with <literal>@Final</literal> annotation are considered to be mandatory in the initializer field typing <literal>@Spec</literal> constructors.
-The already-initialized <literal>@Final</literal> fields can be either omitted from, or can be re-initialized via, an initializer field typing <literal>@Spec</literal> style constructor.</simpara>
-<example>
-<title>Subtype relationship between structural field typing</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A1 {
- public s: string;
-}
-
-class A2 {
- public set s(s: string) { }
- public get s(): string { return null; }
-}
-
-class A3 {
- @Final public s: string = null;
-}
-
-class A4 {
- public get s(): string { return null; }
-}
-
-class A5 {
- public set s(s: string) { }
-}</programlisting>
-<simpara><?asciidoc-pagebreak?></simpara>
-<informaltable role="small" frame="all" rowsep="1" colsep="1">
-<tgroup cols="19">
-<colspec colname="col_1" colwidth="5.2631*"/>
-<colspec colname="col_2" colwidth="5.2631*"/>
-<colspec colname="col_3" colwidth="5.2631*"/>
-<colspec colname="col_4" colwidth="5.2631*"/>
-<colspec colname="col_5" colwidth="5.2631*"/>
-<colspec colname="col_6" colwidth="5.2631*"/>
-<colspec colname="col_7" colwidth="5.2631*"/>
-<colspec colname="col_8" colwidth="5.2631*"/>
-<colspec colname="col_9" colwidth="5.2631*"/>
-<colspec colname="col_10" colwidth="5.2631*"/>
-<colspec colname="col_11" colwidth="5.2631*"/>
-<colspec colname="col_12" colwidth="5.2631*"/>
-<colspec colname="col_13" colwidth="5.2631*"/>
-<colspec colname="col_14" colwidth="5.2631*"/>
-<colspec colname="col_15" colwidth="5.2631*"/>
-<colspec colname="col_16" colwidth="5.2631*"/>
-<colspec colname="col_17" colwidth="5.2631*"/>
-<colspec colname="col_18" colwidth="5.2631*"/>
-<colspec colname="col_19" colwidth="5.2642*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>A1</simpara></entry>
-<entry align="left" valign="top"><simpara>~A1</simpara></entry>
-<entry align="left" valign="top"><simpara>~~A1</simpara></entry>
-<entry align="left" valign="top"><simpara>~r~A1</simpara></entry>
-<entry align="left" valign="top"><simpara>~r~A2</simpara></entry>
-<entry align="left" valign="top"><simpara>~r~A3</simpara></entry>
-<entry align="left" valign="top"><simpara>~r~A4</simpara></entry>
-<entry align="left" valign="top"><simpara>~r~A5</simpara></entry>
-<entry align="left" valign="top"><simpara>~w~A1</simpara></entry>
-<entry align="left" valign="top"><simpara>~w~A2</simpara></entry>
-<entry align="left" valign="top"><simpara>~w~A3</simpara></entry>
-<entry align="left" valign="top"><simpara>~w~A4</simpara></entry>
-<entry align="left" valign="top"><simpara>~w~A5</simpara></entry>
-<entry align="left" valign="top"><simpara>~i~A1</simpara></entry>
-<entry align="left" valign="top"><simpara>~i~A2</simpara></entry>
-<entry align="left" valign="top"><simpara>~i~A3</simpara></entry>
-<entry align="left" valign="top"><simpara>~r~A4</simpara></entry>
-<entry align="left" valign="top"><simpara>~r~A5</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>A1</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~A1</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~~A1</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~r~A1</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~r~A2</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~r~A3</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~r~A4</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~r~A5</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~w~A1</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~w~A2</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~w~A3</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~w~A4</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~w~A5</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~i~A1</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~i~A2</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~i~A3</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~r~A4</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>~r~A5</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"><simpara>✓</simpara></entry>
-<entry align="left" valign="top"></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</example>
-</section>
-<section xml:id="_public-setter-annotated-with-literal-providesinitializer-literal" role="language-n4js">
-<title>Public Setter Annotated With <literal>ProvidesInitializer</literal></title>
-<simpara>Public setters with <literal>ProvidesInitializer</literal> annotation can declare optional fields implemented by means of field accessors instead of data fields.
-Data fields with an initializer are treated as optional in the initializer field type.</simpara>
-<simpara>It is important to note that it is valid to use the <literal>ProvidesInitializer</literal> annotation for setters in <literal>n4js</literal> files and not only definition files.</simpara>
-<example>
-<title>Setters with <literal>@ProvidesInitializer</literal> treated as optional</title>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- private _y: int = 1;
-
- public get y() { return this._y; }
- @ProvidesInitializer
- public set y(v: int) { this._y = v; }
-
- public constructor(@Spec spec: ~i~this) { }
-}
-
-console.log(new C({}).y); // 1
-console.log(new C({y: 42}).y); //24</programlisting>
-</example>
-</section>
-<section xml:id="_structural-types-with-optional-fields" role="language-n4js">
-<title>Structural Types With Optional Fields</title>
-<simpara>Public optional fields become a member of the structural (field) type as
-well. To ensure the overall type safety, the semantics of optionality (e.g. on or off) depends on the context, in which the optional fields are currently being used (See <link linkend="optional-fields">Optional Fields</link>).</simpara>
-</section>
-<section xml:id="_structural-types-with-access-modifier" role="language-n4js">
-<title>Structural Types With Access Modifier</title>
-<simpara>The access modifier of the subtype have to provide equal or higher
-visibility.</simpara>
-<example>
-<title>Access modifier in structural typing</title>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public s: number;
-}
-class D {
- project s: number;
-}
-function f(c: ~C) {}
-f(new D()); // error: D is no (structural) subtype of ~C, as visibility of s in D is lower
-function g(d: ~D) {}
-g(new C()); // ok: C is a (structural) subtype of ~D, as visibility of s in C is greater-than-or-equal to s in D</programlisting>
-</example>
-</section>
-<section xml:id="_structural-types-with-additional-members" role="language-n4js">
-<title>Structural Types With Additional Members</title>
-<simpara>It is possible to add additional members when structurally referencing a
-declared type.</simpara>
-<section xml:id="_syntax-8">
-<title>Syntax</title>
-<programlisting language="xtext" linenumbering="unnumbered">TStructMember:
- TStructGetter | TStructGetterES4 | TStructSetter | TStructMethod | TStructMethodES4 | TStructField;
-
-TStructMethod:
- =>
- ({TStructMethod} ('<' typeVars+=TypeVariable (',' typeVars+=TypeVariable)* '>')?
- returnTypeRef=TypeRef name=TypesIdentifier '(')
- (fpars+=TAnonymousFormalParameter (',' fpars+=TAnonymousFormalParameter)*)? ')'
- ';'?;
-
-TStructMethodES4 returns TStructMethod:
- =>
- ({TStructMethod} ('<' typeVars+=TypeVariable (',' typeVars+=TypeVariable)* '>')?
- name=TypesIdentifier '(')
- (fpars+=TAnonymousFormalParameter (',' fpars+=TAnonymousFormalParameter)*)? ')'
- (':' returnTypeRef=TypeRef)?
- ';'?;
-
-TStructField:
- (
- typeRef=TypeRef name=TypesIdentifier
- | name=TypesIdentifier (':' typeRef=TypeRef)?
- )
- ';';
-
-TStructGetter:
- => ({TStructGetter}
- declaredTypeRef=TypeRef
- 'get'
- name=TypesIdentifier)
- '(' ')' ';'?;
-
-TStructGetterES4 returns TStructGetter:
- => ({TStructGetter}
- 'get'
- name=TypesIdentifier)
- '(' ')' (':' declaredTypeRef=TypeRef)? ';'?;
-
-TStructSetter:
- => ({TStructSetter}
- 'set'
- name=TypesIdentifier)
- '(' fpar=TAnonymousFormalParameter ')' ';'?;
-
-TAnonymousFormalParameter:
- typeRef=TypeRef variadic?='...'? name=TIdentifier?
- | variadic?='...'? (=> name=TIdentifier ':') typeRef=TypeRef;</programlisting>
-<section xml:id="_semantics-6">
-<title>Semantics</title>
-<requirement xml:id="IDE-78">
-<title>Additional structural members</title>
-<simpara>
-<anchor xml:id="Req-IDE-78" xreflabel="[Req-IDE-78]"/>
-<emphasis role="strong">Requirement: IDE-78:</emphasis>
-<link linkend="Req-IDE-78">Additional structural members</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>It is only possible to add additional members to a type if use-site structural typing is used.</simpara>
-<simpara>The following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>For all additional members defined in a structural type reference, the constraints for member overriding (<xref linkend="Req-IDE-72"/>) apply as well.</simpara>
-</listitem>
-<listitem>
-<simpara>All additional members have the access modifier set to <literal>public</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Type variables must not be augmented with additional structural members.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Additional fields may be declared optional in the same way as fields in classes.
-The rules given in <xref linkend="_structural-types-with-optional-fields"/> apply accordingly.
-Consider the following example:</simpara>
-</requirement>
-<example>
-<title>Additional optional members in structural typing</title>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- public f1: number;
-}
-
-var c1: ~C with { f3: string; } c1;
-var c2: ~C with { f3: string?; } c2;
-
-c1 = { f1:42 }; // error: "~Object with { number f1; } is not a subtype of ~C with { string f3; }."
-c2 = { f1:42 }; // ok!!</programlisting>
-</example>
-<simpara>Augmenting a type variable T with additional structural members can cause collisions with another member of a type argument for T.
-Hence, type variables must not be augmented with additional structural members like in the following example.</simpara>
-<example>
-<title>Forbidden additional structural members on type variables</title>
-<programlisting language="n4js" linenumbering="unnumbered">interface I<T> {
- public field : ~T with {prop : int} // error "No additional structural members allowed on type variables."
-}</programlisting>
-</example>
-<simpara>Using an additional structural member on a type variable T could be seen as a constraint to T.
-However, constraints like this should be rather stated using an explicit interface like in the example below.</simpara>
-<example>
-<title>Use explicitly defined Interfaces</title>
-<programlisting language="n4js" linenumbering="unnumbered">interface ~J {
- prop : int;
-}
-interface II<T extends J> {
-}</programlisting>
-</example>
-</section>
-</section>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_functions">
-<title>Functions</title>
-<simpara>Functions, be they function declarations, expressions or even methods, are internally modeled by means of a function type.
-In this chapter, the general function type is described along with its semantics and type constraints.
-Function definitions and expressions are then introduced in terms of statements and expressions.
-Method definitions and special usages are described in <xref linkend="_methods"/>.</simpara>
-<section xml:id="_function-type" role="language-n4js">
-<title>Function Type</title>
-<simpara>A function type is modeled as <literal>Object</literal> (see [<link linkend="ECMA11a">ECMA11a(p.S13, p.p.98)</link>] in ECMAScript.</simpara>
-<simpara>Function types can be defined by means of;</simpara>
-<itemizedlist>
-<listitem>
-<simpara>A function object (<xref linkend="_function-object-type"/>).</simpara>
-</listitem>
-<listitem>
-<simpara>A function type expression (<xref linkend="_type-expressions"/>).</simpara>
-</listitem>
-<listitem>
-<simpara>A function declaration (<xref linkend="_function-declaration"/>).</simpara>
-</listitem>
-<listitem>
-<simpara>A method declaration (<xref linkend="_methods"/>).</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="_properties-5">
-<title>Properties</title>
-<simpara>In any case, a function type declares the signature of a function and allows validation of calls to that function.
-A function type has the following properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>typePars</literal> </term>
-<listitem>
-<simpara>(0-indexed) list of type parameters (i.e. type variables) for generic functions.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fpars</literal> </term>
-<listitem>
-<simpara>(0-indexed) list of formal parameters.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>returnType</literal> </term>
-<listitem>
-<simpara>(possibly inferred) return type (expression) of the function or method.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>name</literal> </term>
-<listitem>
-<simpara>Name of function or method, may be empty or automatically generated (for messages).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>body</literal> </term>
-<listitem>
-<simpara>The body of the function, it contains statements <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>t</mi><mi>m</mi><mi>t</mi><mi>s</mi></math>.
-The body is null if a function type is defined in a type expression, and it is the last argument in case of a function object constructor, or the content of the function definition body.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Additionally, the following pseudo properties for functions are defined:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>thisTypeRef</literal> </term>
-<listitem>
-<simpara>The this type ref is the type to which the <literal>this</literal>-keyword would be evaluated
-if used inside the function or member. The inference rules are described
-in <xref linkend="_this-keyword"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fpars</literal> </term>
-<listitem>
-<simpara>List of formal parameters and the this type ref.
-This is only used for sub typing rules.
-If <literal>this</literal> is not used inside the function, then <literal>any</literal> is set instead of the inferred thisTypeRef to allow for more usages.
-The property is computed as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>t</mi><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>=</mo><mstyle mathvariant="bold"><mtext>if</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mspace width="3.0mm"/><mstyle mathvariant="bold"><mtext>this is used or explicitly declared</mtext></mstyle><mspace width="3.0mm"/><mstyle mathvariant="bold"><mtext>then</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>+</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mspace width="3.0mm"/><mstyle mathvariant="bold"><mtext>else</mtext></mstyle><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mi>a</mi><mi>n</mi><mi>y</mi><mo>+</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi></math>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Parameters (in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi></math>) have the following properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>name</literal> </term>
-<listitem>
-<simpara>Name of the parameter.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>type</literal> </term>
-<listitem>
-<simpara>Type (expression) of the parameter. Note that only parameter types can
-be variadic or optional.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The function definition can be annotated similar to <xref linkend="_methods"/> except that the <literal>final</literal> and <literal>abstract</literal> modifiers aren’t supported for function declarations.
-A function declaration is always final and never abstract.
-Also, a function has no property advice set.</simpara>
-<bridgehead xml:id="_semantics-7" renderas="sect3">Semantics</bridgehead>
-<requirement xml:id="IDE-79">
-<title>Function Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-79" xreflabel="[Req-IDE-79]"/>
-<emphasis role="strong">Requirement: IDE-79:</emphasis>
-<link linkend="Req-IDE-79">Function Type</link> (ver. 1)</simpara>
- <simpara>
-
-Type Given a function type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math>, the following constraints must be true:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Optional parameters must be defined at the end of the (formal) parameter list.
-In particular, an optional parameter must not be followed by a non-optional parameter:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>F</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>→</mo><mo>∄</mo><mi>k</mi><mo>></mo><mi>i</mi><mi>:</mi><mo>¬</mo><mi>F</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>k</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mi>v</mi><mi>a</mi><mi>r</mi></math>
-</listitem>
-<listitem>
-<simpara>Only the last parameter of a method may be defined as variadic parameter:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>F</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>i</mi><mi>a</mi><mi>d</mi><mi>i</mi><mi>c</mi><mo>→</mo><mi>i</mi><mo>=</mo><mo>|</mo><mi>F</mi><mo>.</mo><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>-</mo><mn>1</mn></math>
-</listitem>
-<listitem>
-<simpara>If a function explicitly defines a return type, the last statement of the transitive closure of statements of the body must be a return statement:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>≠</mo><mi>U</mi><mi>n</mi><mi>d</mi><mi>e</mi><mi>f</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mo>→</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>f</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>m</mi><mi>t</mi><mi>s</mi><mo>|</mo><mo>></mo><mn>0</mn></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∧</mo><mi>f</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>m</mi><mi>t</mi><msubsup><mi>s</mi><mrow><mo>|</mo><mi>f</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>m</mi><mi>t</mi><msup><mi>s</mi><mo>*</mo></msup><mo>|</mo><mo>-</mo><mn>1</mn></mrow><mo>*</mo></msubsup><mi>i</mi><mi>s</mi><mi>a</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>ReturnStatement</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara>If a function explicitly defines a return type, all return
-statements must return a type conform to that type:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>F</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>≠</mo><mi>U</mi><mi>n</mi><mi>d</mi><mi>e</mi><mi>f</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>⇔</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∀</mo><mi>r</mi><mo>∈</mo><mi>F</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>m</mi><mi>t</mi><mi>s</mi><mo>,</mo><mi>r</mi><mi> </mi><mi>i</mi><mi>s</mi><mi>a</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>ReturnStatement</mtext></mstyle><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>r</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>r</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mo><</mo><mi>:</mi><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>F</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="function-type-inference">
-<title>Type Inference</title>
-<definition xml:id="function_type_conformance_non_parameterized">
-<title>Function Type Conformance Non-Parameterized</title>
-<simpara>
-<anchor xml:id="function_type_conformance_non-parameterized" xreflabel="[function_type_conformance_non-parameterized]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="function_type_conformance_non-parameterized">Function Type Conformance Non-Parameterized</link></simpara>
-<simpara>
-
-<emphasis>For the given non-parameterized function types</emphasis>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub></math> with
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>=</mo><msub><mi>L</mi><mn>0</mn></msub><mo>,</mo><msub><mi>L</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><msub><mi>L</mi><mi>k</mi></msub></math> and
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>s</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>=</mo><mn>0</mn></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math> with
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>=</mo><msub><mi>R</mi><mn>0</mn></msub><mo>,</mo><msub><mi>R</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><msub><mi>R</mi><mi>n</mi></msub></math> and
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>s</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>=</mo><mn>0</mn></math>,<?asciidoc-br?>
-we say <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub></math> conforms to <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math>,
-written as <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo><</mo><mi>:</mi><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math>, if and only if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∨</mo><mfenced close=")" open="("><mrow><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle><mo>∧</mo><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></mrow></mfenced></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∨</mo><mrow><mo>(</mo><mrow><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo><</mo><mi>:</mi><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>∧</mo><mo>¬</mo><mfenced close=")" open="("><mrow><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>∧</mo><mo>¬</mo><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></mrow></mfenced><mo>)</mo></mrow></mrow></math></simpara>
-</listitem>
-<listitem>
-<simpara>if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mo>≤</mo><mi>n</mi></math>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi> </mi><mi>i</mi><mo>,</mo><mn>1</mn><mo>≤</mo><mi>i</mi><mo>≤</mo><mi>k</mi><mi>:</mi><mfenced close=")" open="("><mrow><msub><mi>R</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>→</mo><mfenced close=")" open="("><mrow><msub><mi>L</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>∨</mo><msub><mi>L</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mrow></mfenced></mrow></mfenced><mo>∧</mo><mfenced close=")" open="("><mrow><msub><mi>R</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>→</mo><msub><mi>L</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mrow></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi> </mi><mi>i</mi><mo>,</mo><mn>1</mn><mo>≤</mo><mi>i</mi><mo>≤</mo><mi>k</mi><mi>:</mi><msub><mi>L</mi><mi>i</mi></msub><mi>:</mi><mo>></mo><msub><mi>R</mi><mi>i</mi></msub></math></simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>L</mi><mi>k</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>=</mo><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi><mo>→</mo><mo>∀</mo><mi> </mi><mi>i</mi><mo>,</mo><mi>k</mi><mo><</mo><mi>i</mi><mo>≤</mo><mi>n</mi><mi>:</mi><msub><mi>L</mi><mi>K</mi></msub><mi>:</mi><mo>></mo><msub><mi>R</mi><mi>i</mi></msub></math></simpara>
-<simpara>else (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mo>></mo><mi>n</mi></math>):</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi> </mi><mi>i</mi><mo>,</mo><mn>1</mn><mo>≤</mo><mi>i</mi><mo>≤</mo><mi>n</mi><mi>:</mi><mfenced close=")" open="("><mrow><msub><mi>R</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>→</mo><mfenced close=")" open="("><mrow><msub><mi>L</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>∨</mo><msub><mi>L</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mrow></mfenced></mrow></mfenced><mo>∧</mo><mfenced close=")" open="("><mrow><msub><mi>R</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>→</mo><msub><mi>L</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></mrow></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi> </mi><mi>i</mi><mo>,</mo><mn>1</mn><mo>≤</mo><mi>i</mi><mo>≤</mo><mi>n</mi><mi>:</mi><msub><mi>L</mi><mi>i</mi></msub><mi>:</mi><mo>></mo><msub><mi>R</mi><mi>i</mi></msub></math></simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi> </mi><mi>n</mi><mo><</mo><mi>i</mi><mo>≤</mo><mi>k</mi><mi>:</mi><msub><mi>L</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mo>∨</mo><msub><mi>L</mi><mi>i</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>R</mi><mi>n</mi></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>=</mo><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi><mo>→</mo><mo>∀</mo><mi> </mi><mi>i</mi><mo>,</mo><mi>n</mi><mo><</mo><mi>i</mi><mo>≤</mo><mi>k</mi><mi>:</mi><msub><mi>L</mi><mi>i</mi></msub><mi>:</mi><mo>></mo><msub><mi>R</mi><mi>n</mi></msub></math></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-<simpara><xref linkend="cdVarianceFunctionChart"/> shows a simple example with the function type conformance relations.</simpara>
-<figure xml:id="cdVarianceFunctionChart">
-<title>Function Variance Chart</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/06_functions/fig/cdVarianceFunctionChart.svg" width="60%" scalefit="1"/>
-</imageobject>
-<textobject><phrase>cdVarianceFunctionChart</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><literal>{function()}</literal> <math xmlns="http://www.w3.org/1998/Math/MathML"><mo><</mo><mi>:</mi></math> <literal>{function(A)}</literal> <math xmlns="http://www.w3.org/1998/Math/MathML"><mo><</mo><mi>:</mi></math> <literal>{function(A, A)}</literal> might be surprising for Java programmers. However, in JavaScript it is
-possible to call a function with any number of arguments independently
-from how many formal parameters the function defines.</simpara>
-<simpara>If a function does not define a return type, <literal>any</literal> is assumed if at least one
-of the (indirectly) contained return statements contains an expression.
-Otherwise <literal>void</literal> is assumed. This is also true if there is an error due to
-other constraint violations.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mspace width="3.0mm"/><mfrac><mrow><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mi>s</mi><mfenced close=")" open="("><mi>f</mi><mi>F</mi></mfenced><mspace width="3.0mm"/><mi>F</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle><mspace width="3.0mm"/><mo>∃</mo><mi>r</mi><mo>∈</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>s</mi><mfenced close=")" open="("><mi>F</mi></mfenced><mi>:</mi><mi>r</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>f</mi><mstyle mathvariant="monospace"><mtext>’(’</mtext></mstyle><mi>a</mi><mi>r</mi><mi>g</mi><mi>l</mi><mi>i</mi><mi>s</mi><mi>t</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’)’</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mfrac><mrow><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mi>s</mi><mfenced close=")" open="("><mi>f</mi><mi>F</mi></mfenced><mspace width="3.0mm"/><mi>F</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle><mspace width="3.0mm"/><mo>∀</mo><mi>r</mi><mo>∈</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>s</mi><mfenced close=")" open="("><mi>F</mi></mfenced><mi>:</mi><mi>r</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>f</mi><mstyle mathvariant="monospace"><mtext>’(’</mtext></mstyle><mi>a</mi><mi>r</mi><mi>g</mi><mi>l</mi><mi>i</mi><mi>s</mi><mi>t</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’)’</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-<simpara>with</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mspace width="3.0mm"/><mfrac><mrow><mfenced close="}" open="{"><mrow><mi>r</mi><mo>∈</mo><mi>F</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>e</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mo>|</mo><mi>μ</mi><mfenced close=")" open="("><mi>r</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>ReturnStatement</mtext></mstyle></mrow></mfenced><mo>∪</mo><munder><mo>⋃</mo><mrow><mi>s</mi><mo>∈</mo><mi>F</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>e</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi></mrow></munder><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>s</mi><mfenced close=")" open="("><mi>s</mi></mfenced></mrow><mrow><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>s</mi><mfenced close=")" open="("><mi>F</mi></mfenced><mi>:</mi><mi>R</mi><mi>E</mi><mi>T</mi><mi>S</mi></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mfrac><mrow><mfenced close="}" open="{"><mrow><mi>s</mi><mi>u</mi><mi>b</mi><mo>∈</mo><mi>s</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>e</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mo>|</mo><mi>μ</mi><mfenced close=")" open="("><mrow><mi>s</mi><mi>u</mi><mi>b</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>ReturnStatement</mtext></mstyle></mrow></mfenced><mo>∪</mo><munder><mo>⋃</mo><mrow><mi>s</mi><mi>u</mi><mi>b</mi><mo>∈</mo><mi>s</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>e</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi></mrow></munder><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>s</mi><mfenced close=")" open="("><mrow><mi>s</mi><mi>u</mi><mi>b</mi></mrow></mfenced></mrow><mrow><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>s</mi><mfenced close=")" open="("><mi>s</mi></mfenced><mi>:</mi><mi>R</mi><mi>E</mi><mi>T</mi><mi>S</mi></mrow></mfrac></mtd></mtr></mtable></math>
-</definition>
-<example>
-<title>Function type conformance</title>
-<simpara>The following incomplete snippet demonstrates the usage of two function variables <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>1</mn></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>2</mn></math>, in which <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>f</mi><mn>2</mn></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mo><</mo><mi>:</mi><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>f</mi><mn>1</mn></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math> must hold true according to the aforementioned constraints.
-A function <literal>bar</literal> declares a parameter <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>1</mn></math>, which is actually a function itself.
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>2</mn></math> is a variable, to which a function expression is a assigned.
-Function <literal>bar</literal> is then called with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>2</mn></math> as an argument.
-Thus, the type of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>2</mn></math> must be a subtype of the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>1</mn></math>’s type.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">function bar(f1: {function(A,B):C}) { ... }
-
-var f2: {function(A,B):C} = function(p1,p2){...};
-bar(f1);</programlisting>
-</example>
-<simpara>The type of <literal>this</literal> can be explicitly set via the <literal>@This</literal> annotation.</simpara>
-<example>
-<title>Function Subtyping</title>
-<programlisting language="n4js" linenumbering="unnumbered">function f(): A {..}
-function p(): void {..}
-
-fAny(log: {function():any}) {...}
-fVoid(f: {function():void}) {..}
-fA(g: {function():A}) {...}
-
-fAny(f); // --> ok A <: any
-fVoid(f); // -->error A !<: void
-fA(f); // --> ok (easy) A <: A
-
-fAny(p); // --> ok void <: any
-fVoid(p); // --> ok void <: void
-fA(p); // --> error void !<: A</programlisting>
-</example>
-<example>
-<title>Subtyping with function types</title>
-<simpara>If classes A, B, and C are defined as previously mentioned, i.e. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo><</mo><mi>:</mi><mi>B</mi><mo><</mo><mi>:</mi><mi>A</mi></math>, then
-the following subtyping relations with function types are to be evaluated as follows:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> {function(B):B} <: {function(B):B} -> true
- {function():A} <: {function():B} -> false
- {function():C} <: {function():B} -> true
- {function(A)} <: {function(B)} -> true
- {function(C)} <: {function(B)} -> false
-
- {function():void} <: {function():void} -> true
-{function():undefined} <: {function():void} -> true
- {function():void} <: {function():undefined} -> true (!)
-
- {function():B} <: {function():void} -> true (!)
- {function():B} <: {function():undefined} -> false (!)
- {function():void} <: {function():B} -> false
-{function():undefined} <: {function():B} -> true</programlisting>
-<simpara>The following examples demonstrate the effect of optional and variadic parameters:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">{function(A)} <: {function(B)} -> true
-{function(A...)} <: {function(A)} -> true
-{function(A, A)} <: {function(A)} -> false
-{function(A)} <: {function(A,A)} -> true (!)
-{function(A, A...)} <: {function(A)} -> true
-{function(A)} <: {function(A,A...)} -> true (!)
-{function(A, A...)} <: {function(B)} -> true
-{function(A?)} <: {function(A?)} -> true
-{function(A...)} <: {function(A...)} -> true
-{function(A?)} <: {function(A)} -> true
-{function(A)} <: {function(A?)} -> false
-{function(A...)} <: {function(A?)} -> true
-{function(A?)} <: {function(A...)} -> true (!)
-{function(A,A...)} <: {function(A...)} -> false
-{function(A,A?)} <: {function(A...)} -> false
-{function(A?,A...)} <: {function(A...)} -> true
-{function(A...)} <: {function(A?,A...)} -> true
-{function(A...)} <: {function(A?)} -> true
-{function(A?,A?)} <: {function(A...)} -> true (!)
-{function(A?,A?,A?)} <: {function(A...)} -> true (!)
-{function(A?)} <: {function()} -> true (!)
-{function(A...)} <: {function()} -> true (!)</programlisting>
-<simpara>The following examples demonstrate the effect of optional return types:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">{function():void} <: {function():void} -> true
-{function():X} <: {function():void} -> true
-{function():X?} <: {function():void} -> true
-{function():void} <: {function():Y} -> false
-{function():X} <: {function():Y} -> X <: Y
-{function():X?} <: {function():Y} -> false (!)
-{function():void} <: {function():Y?} -> true (!)
-{function():X} <: {function():Y?} -> X <: Y
-{function():X?} <: {function():Y?} -> X <: Y
- {function():B?} <: {function():undefined} -> false (!)
-{function():undefined} <: {function():B?} -> true</programlisting>
-<simpara>The following examples show the effect of the <literal>@This</literal> annotation:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">{@This(A) function():void} <: {@This(X) function():void} -> false
-{@This(B) function():void} <: {@This(A) function():void} -> false
-{@This(A) function():void} <: {@This(B) function():void} -> true
-{@This(any) function():void} <: {@This(X) function():void} -> true
-{function():void} <: {@This(X) function():void} -> true
-{@This(A) function():void} <: {@This(any) function():void} -> false
-{@This(A) function():void} <: {function():void} -> false</programlisting>
-</example>
-<definition>
-<title>Function Type Conformance</title>
-<simpara>
-<anchor xml:id="function_type_conformance" xreflabel="[function_type_conformance]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="function_type_conformance">Function Type Conformance</link></simpara>
-<simpara>
-
-For the given function types<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub></math> with
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>=</mo><msub><mi>L</mi><mn>0</mn></msub><mo>,</mo><msub><mi>L</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><msub><mi>L</mi><mi>k</mi></msub></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math> with
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>=</mo><msub><mi>R</mi><mn>0</mn></msub><mo>,</mo><msub><mi>R</mi><mn>1</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><msub><mi>R</mi><mi>n</mi></msub></math>,<?asciidoc-br?>
-we say <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub></math> conforms to <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math>, written as <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo><</mo><mi>:</mi><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math>, if and only if:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>if <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>=</mo><mo>|</mo><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>=</mo><mn>0</mn></math>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo><</mo><mi>:</mi><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math>
-(cf. <link linkend="function_type_conformance_non_parameterized">Function Type Conformance Non-Parameterized</link>)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>else if<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>></mo><mn>0</mn><mo>∧</mo><mo>|</mo><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>=</mo><mn>0</mn></math>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∃</mo><mi>θ</mi><mi>:</mi><mfenced close=")" open="("><mrow><mi>Γ</mi><mo>←</mo><mi>θ</mi></mrow></mfenced><mo>⊢</mo><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo><</mo><mi>:</mi><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math> (cf. <link linkend="function_type_conformance_non_parameterized">Function Type Conformance Non-Parameterized</link> )</simpara>
-<simpara>(i.e. there exists a substitution <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>θ</mi></math> of type variables in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub></math> so that after substitution it becomes a subtype of <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math> as defined by <link linkend="function_type_conformance_non_parameterized">Function Type Conformance Non-Parameterized</link>)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>else if <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>=</mo><mo>|</mo><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo></math>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>←</mo><mfenced close="}" open="{"><mrow><msubsup><mi>V</mi><mi>i</mi><mi>r</mi></msubsup><mo>←</mo><msubsup><mi>V</mi><mi>i</mi><mi>l</mi></msubsup><mo>|</mo><mn>0</mn><mo>≤</mo><mi>i</mi><mo>≤</mo><mi>n</mi></mrow></mfenced><mo>⊢</mo><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo><</mo><mi>:</mi><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math>
-( accordingly)</simpara>
-</listitem>
-<listitem>
-<simpara>-</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mo>∀</mo><mn>0</mn><mo>≤</mo><mi>i</mi><mo>≤</mo><mi>n</mi><mi>:</mi></mtd></mtr><mtr><mtd><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msubsup><mi>V</mi><mi>i</mi><mi>l</mi></msubsup><mo>.</mo><mstyle mathvariant="italic"><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></mstyle></mrow></mfenced><mi>:</mi><mo>></mo><mi>i</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>e</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><msubsup><mi>V</mi><mi>i</mi><mi>r</mi></msubsup><mo>.</mo><mstyle mathvariant="italic"><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></mstyle></mrow></mfenced></mtd></mtr></mtable></math>
-<simpara>with <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>=</mo><msubsup><mi>V</mi><mn>0</mn><mi>l</mi></msubsup><mo>,</mo><msubsup><mi>V</mi><mn>1</mn><mi>l</mi></msubsup><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><msubsup><mi>V</mi><mi>n</mi><mi>l</mi></msubsup></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>=</mo><msubsup><mi>V</mi><mn>0</mn><mi>r</mi></msubsup><mo>,</mo><msubsup><mi>V</mi><mn>1</mn><mi>r</mi></msubsup><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><msubsup><mi>V</mi><mi>n</mi><mi>r</mi></msubsup></math><?asciidoc-br?>
-(i.e. we replace each type variable in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math> by the corresponding type variable at the same index in <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub></math>
-and check the constraints from <link linkend="function_type_conformance_non_parameterized">Function Type Conformance Non-Parameterized</link> as if <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></msub></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>F</mi><mrow><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></mrow></msub></math> were non-parameterized functions and, in
-addition, the upper bounds on the left side need to be supertypes of the upper bounds on the right side).</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</definition>
-<simpara>Note that the upper bounds on the left must be supertypes of the right-side upper bounds (for similar reasons why types of formal parameters on the left are
-required to be supertypes of the formal parameters’ types in ).
-Where a particular type variable is used, on co- or contra-variant position, is not relevant:</simpara>
-<example>
-<title>Bounded type variable at co-variant position in function type</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A {}
-class B extends A {}
-
-class X {
- <T extends B> m(): T { return null; }
-}
-class Y extends X {
- @Override
- <T extends A> m(): T { return null; }
-}</programlisting>
-<simpara>Method <literal>m</literal> in <literal>Y</literal> may return an <literal>A</literal>, thus breaking the contract of m in <literal>X</literal>, but only if it is parameterized to do so, which is not allowed for clients of <literal>X</literal>, only those of <literal>Y</literal>.
-Therefore, the override in the above example is valid.</simpara>
-</example>
-<simpara>The subtype relation for function types is also applied for method overriding to ensure that an overriding method’s signature conforms to that of the overridden method,
-see <xref linkend="Req-IDE-72"/> (applies to method comnsumption and implementation accordingly, see <xref linkend="Req-IDE-73"/> and <xref linkend="Req-IDE-74"/>).
-Note that this is very different from Java which is far more restrictive when checking overriding methods.
-As Java also supports method overloading: given two types <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>A</mi><mo>,</mo><mi>B</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>B</mi><mo><</mo><mi>:</mi><mi>A</mi></math> and a super class method <literal>void m(B param)</literal>, it is valid to override <literal>m</literal> as <literal>void m(A param)</literal> in N4JS but not in Java.
-In Java this would be handled as method overloading and therefore an <literal>@Override</literal> annotation on <literal>m</literal> would produce an error.</simpara>
-<requirement xml:id="IDE-80">
-<title>Upper and Lower Bound of a Function Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-80" xreflabel="[Req-IDE-80]"/>
-<emphasis role="strong">Requirement: IDE-80:</emphasis>
-<link linkend="Req-IDE-80">Upper and Lower Bound of a Function Type</link> (ver. 1)</simpara>
- <simpara>
-
-The upper bound of a function type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> is a function type with the lower bound types of the parameters and the upper bound of the return type:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mrow><mstyle mathvariant="monospace"><mtext>function</mtext></mstyle><mfenced close=")" open="("><msub><mi>P</mi><mn>1</mn></msub><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><msub><mi>P</mi><mi>n</mi></msub></mfenced><mi>:</mi><mi>R</mi></mrow></mfenced><mi>:</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>function</mtext></mstyle><mfenced close=")" open="("><mrow><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>P</mi><mn>1</mn></msub></mfenced></mrow><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mrow><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>P</mi><mi>n</mi></msub></mfenced></mrow></mfenced><mi>:</mi><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mi>R</mi></mfenced></math></simpara>
-<simpara>The lower bound of a function type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> is a function type with the upper bound types of the parameters and the lower bound of the return type:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mrow><mstyle mathvariant="monospace"><mtext>function</mtext></mstyle><mfenced close=")" open="("><msub><mi>P</mi><mn>1</mn></msub><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><msub><mi>P</mi><mi>n</mi></msub></mfenced><mi>:</mi><mi>R</mi></mrow></mfenced><mi>:</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>function</mtext></mstyle><mfenced close=")" open="("><mrow><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>P</mi><mn>1</mn></msub></mfenced></mrow><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow><mrow><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><msub><mi>P</mi><mi>n</mi></msub></mfenced></mrow></mfenced><mi>:</mi><mi>l</mi><mi>o</mi><mi>w</mi><mi>e</mi><mi>r</mi><mfenced close=")" open="("><mi>R</mi></mfenced></math></simpara>
-</requirement>
-</section>
-<section xml:id="_autoboxing-of-function-type">
-<title>Autoboxing of Function Type</title>
-<simpara>Function types, compared to other types like String, come only in on flavour: the Function object representation.
-There is no primitive function type.
-Nevertheless, for function type expressions and function declarations, it is possible to call the properties of Function object directly.
-This is similar to autoboxing for strings.</simpara>
-<formalpara>
-<title>Access of Function properties on functions</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">// function declaration
-var param: number = function(a,b){}.length // 2
-
-function a(x: number) : number { return x*x; }
-// function reference
-a.length; // 1
-
-// function variable
-var f = function(m,l,b){/*...*/};
-f.length; // 3
-
-class A {
- s: string;
- sayS(): string{ return this.s; }
-}
-
-var objA: A = new A();
-objA.s = "A";
-
-var objB = {s:"B"}
-
-// function variable
-var m = objA.sayS; // method as function, detached from objA
-var mA: {function(any)} = m.bind(objA); // bind to objA
-var mB: {function(any)} = m.bind(objB); // bind to objB
-
-m() // returns: undefined
-mA() // returns: A
-mB() // returns: B
-
-m.call(objA,1,2,3); // returns: A
-m.apply(objB,[1,2,3]); // returns: B
-m.toString(); // returns: function sayS(){ return this.s; }</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="_arguments-object">
-<title>Arguments Object</title>
-<simpara>A special arguments object is defined within the body of a function.
-It is accessible through the implicitly-defined local variable named ,
-unless it is shadowed by a local variable, a formal parameter or a
-function named <literal>arguments</literal> or in the rare case that the function itself is called ’arguments’ [<link linkend="ECMA11a">ECMA11a(p.S10.5, p.p.59)</link>].
-The argument object has array-like behavior even though it is not of type <literal>array</literal>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>All actual passed-in parameters of the current execution context can be retrieved by <math xmlns="http://www.w3.org/1998/Math/MathML"><mn>0</mn><mo>-</mo><mi>b</mi><mi>a</mi><mi>s</mi><mi>e</mi><mi>d</mi></math> index access.</simpara>
-</listitem>
-<listitem>
-<simpara>The <literal>length</literal> property of the arguments object stores the actual number of passed-in arguments which may differ from the number of formally defined number of parameters <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi></math> of the containing function.</simpara>
-</listitem>
-<listitem>
-<simpara>It is possible to store custom values in the arguments object, even outside the original index boundaries.</simpara>
-</listitem>
-<listitem>
-<simpara>All obtained values from the arguments object are of type <literal>any</literal>.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>In non-strict ES mode the <literal>callee</literal> property holds a reference to the function executed [<link linkend="ECMA11a">ECMA11a(p.S10.6, p.p.61)</link>].</simpara>
-<requirement xml:id="IDE-81">
-<title>Arguments.callee</title>
-<simpara>
-<anchor xml:id="Req-IDE-81" xreflabel="[Req-IDE-81]"/>
-<emphasis role="strong">Requirement: IDE-81:</emphasis>
-<link linkend="Req-IDE-81">Arguments.callee</link> (ver. 1)</simpara>
- <simpara>
-
-In N4JS and in ES strict mode the use of <literal>arguments.callee</literal> is prohibited.</simpara>
-</requirement>
-<requirement xml:id="IDE-82">
-<title>Arguments as formal parameter name</title>
-<simpara>
-<anchor xml:id="Req-IDE-82" xreflabel="[Req-IDE-82]"/>
-<emphasis role="strong">Requirement: IDE-82:</emphasis>
-<link linkend="Req-IDE-82">Arguments as formal parameter name</link> (ver. 1)</simpara>
- <simpara>
-
-In N4JS, the formal parameters of the function cannot be named <literal>arguments</literal>.
-This applies to all variable execution environments like field accessors (getter/setter, <xref linkend="_field-accessors-getter-setter"/>),
-methods (<xref linkend="_methods"/>) and constructors (<xref linkend="_constructor-and-classifier-type"/>), where <literal>FormalParameter</literal> type is used.</simpara>
-</requirement>
-<programlisting language="n4js" linenumbering="unnumbered">// regular function
-function a1(s1: string, n2: number) {
- var l: number = arguments.length;
- var s: string = arguments[0] as string;
-}
-
-class A {
- // property access
- get s(): string { return ""+arguments.length; } // 0
- set s(n: number) { console.log( arguments.length ); } // 1
- // method
- m(arg: string) {
- var l: number = arguments.length;
- var s: string = arguments[0] as string;
- }
-}
-
-// property access in object literals
-var x = {
- a:5,
- get b(): string {
- return ""+arguments.length
- }
-}
-
-// invalid:
-function z(){
- arguments.length // illegal, see next lines
- // define arguments to be a plain variable of type number:
- var arguments: number = 4;
-}</programlisting>
-</section>
-</section>
-<section xml:id="_ecmascript-5-function-definition" role="language-n4js">
-<title>ECMAScript 5 Function Definition</title>
-<section xml:id="_function-declaration">
-<title>Function Declaration</title>
-<section xml:id="_syntax-9">
-<title>Syntax</title>
-<simpara>A function can be defined as described in [<link linkend="ECMA11a">ECMA11a(p.S13, p.p.98)</link>] and additional annotations can be specified.
-Since N4JS is based on [<link linkend="ECMA15a">ECMA15a</link>], the syntax contains constructs not available in [<link linkend="ECMA11a">ECMA11a</link>].
-The newer constructs defined only in [<link linkend="ECMA15a">ECMA15a</link>] and proposals already implemented in N4JS are described in <xref linkend="_ecmascript-2015-function-definition"/> and <xref linkend="_ecmascript-proposals-function-definition"/>.</simpara>
-<note>
-<simpara>In contrast to plain JavaScript, function declarations can be used in blocks in N4JS.
-This is only true, however, for N4JS files, not for plain JS files.</simpara>
-</note>
-<formalpara>
-<title>Syntax Function Declaration and Expression</title>
-<para>
-<programlisting language="xtext" linenumbering="unnumbered">FunctionDeclaration <Yield>:
- => ({FunctionDeclaration}
- annotations+=Annotation*
- (declaredModifiers+=N4Modifier)*
- -> FunctionImpl <Yield,Yield,Expression=false>
- ) => Semi?
-;
-
-
-fragment AsyncNoTrailingLineBreak *: (declaredAsync?='async' NoLineTerminator)?;
-
-fragment FunctionImpl<Yield, YieldIfGenerator, Expression>*:
- 'function'
- (
- generator?='*' FunctionHeader<YieldIfGenerator,Generator=true> FunctionBody<Yield=true,Expression>
- | FunctionHeader<Yield,Generator=false> FunctionBody<Yield=false,Expression>
- )
-;
-
-fragment FunctionHeader<Yield, Generator>*:
- TypeVariables?
- name=BindingIdentifier<Yield>?
- StrictFormalParameters<Yield=Generator>
- (-> ':' returnTypeRef=TypeRef)?
-;
-
-fragment FunctionBody <Yield, Expression>*:
- <Expression> body=Block<Yield>
- | <!Expression> body=Block<Yield>?
-;</programlisting>
-</para>
-</formalpara>
-<simpara>Properties of the function declaration and expression are described in <xref linkend="_function-type"/>.</simpara>
-<simpara>For this specification, we introduce a supertype <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>D</mi><mi>e</mi><mi>f</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi></math> for both, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></math>.
-This supertype contains all common properties of these two subtypes, that is, all properties of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></math>.</simpara>
-<example>
-<title>Function Declaration with Type Annotation</title>
-<programlisting language="n4js" linenumbering="unnumbered">// plain JS
-function f(p) { return p.length }
-// N4JS
-function f(p: string): number { return p.length }</programlisting>
-</example>
-</section>
-<section xml:id="_semantics-8">
-<title>Semantics</title>
-<simpara>A function defined in a class’s method (or method modifier) builder is a method, see <xref linkend="_methods"/> for details and additional constraints.
-The metatype of a function definition is function type (<xref linkend="_function-type"/>), as a function declaration is only a different syntax for creating a <literal>Function</literal> object.
-Constraints for function type are described in <xref linkend="_function-type"/>.
-Another consequence is that the inferred type of a function definition <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi></math> is simply its function type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math>.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>f</mi><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></mrow><mrow><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mi>F</mi><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></mrow></mfrac></math>
-<simpara>Note that the type of a function definition is different from its return type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi></math>!</simpara>
-<requirement xml:id="IDE-83">
-<title>Function Declaration only on Top-Level</title>
-<simpara>
-<anchor xml:id="Req-IDE-83" xreflabel="[Req-IDE-83]"/>
-<emphasis role="strong">Requirement: IDE-83:</emphasis>
-<link linkend="Req-IDE-83">Function Declaration only on Top-Level</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>In plain JavaScript, function declarations must only be located on top-level, that is they must not be nested in blocks.
-Since this is supported by most JavaScript engines, only a warning is issued.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-</section>
-<section xml:id="_function-expression">
-<title>Function Expression</title>
-<simpara>A function expression [<link linkend="ECMA11a">ECMA11a(p.S11.2.5)</link>] is quite similar to a function declaration.
-Thus, most details are explained in <xref linkend="_ecmascript-5-function-definition"/>.</simpara>
-<section xml:id="function-expression-syntax">
-<title>Syntax</title>
-<programlisting language="xtext" linenumbering="unnumbered">FunctionExpression:
- ({FunctionExpression}
- FunctionImpl<Yield=false,YieldIfGenerator=true,Expression=true>
- )
-;</programlisting>
-</section>
-<section xml:id="_semantics-and-type-inference">
-<title>Semantics and Type Inference</title>
-<simpara>In general, the inferred type of a function expression simply is the function type as described in <xref linkend="_function-type"/>.
-Often, the signature of a function expression is not explicitly specified but it can be inferred from the context.
-The following context information is used to infer the full signature:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If the function expression is used on the right hand side of an assignment, the expected return type can be inferred from the left hand side.</simpara>
-</listitem>
-<listitem>
-<simpara>If the function expression is used as an argument in a call to another function, the full signature can be inferred from the corresponding type of the formal parameter declaration.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Although the signature of the function expression may be inferred from the formal parameter if the function expression is used as argument, this inference has some conceptual limitations.
-This is demonstrated in the next example.</simpara>
-<example>
-<title>Inference Of Function Expression’s Signature</title>
-<simpara>In general, <literal>{function():any}</literal> is a subtype of <literal>{function():void}</literal> (cf. <xref linkend="_function-type"/>).
-When the return type of a function expression is inferred, this relation is taken into account which may lead to unexpected results as shown in the following code snippet:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">function f(cb: {function():void}) { cb() }
-f(function() { return 1; });</programlisting>
-<simpara>No error is issued: The type of the function expression actually is inferred to <literal>{function():any}</literal>, because there is a return statement with an expression.
-It is not inferred to <literal>{function():void}</literal>, even if the formal parameter of <literal>f</literal> suggests that.
-Due to the previously-stated relation <literal>{function():any} <: {function():void}</literal> this is correct – the client (in this
-case function <literal>f</literal>) works perfectly well even if <literal>cb</literal> returns something.
-The contract of arguments states that the type of the argument is a subtype of the type of the formal parameter.
-This is what the inferencer takes into account!</simpara>
-</example>
-</section>
-</section>
-</section>
-<section xml:id="_ecmascript-2015-function-definition" role="language-n4js">
-<title>ECMAScript 2015 Function Definition</title>
-<section xml:id="_formal-parameters">
-<title>Formal Parameters</title>
-<simpara>Parameter handling has been significantly upgraded in ECMAScript 6.
-It now supports parameter default values, rest parameters (variadics) and destructuring.
-Formal parameters can be modified to be either default or variadic.
-In case a formal parameter has no modifier, it is called normal.
-Modified parameters also become optional.</simpara>
-<simpara>Modifiers of formal parameters such as default or rest are neither evaluated nor rewritten in the transpiler.</simpara>
-<section xml:id="Type_Modifiers_Optional">
-<title>Optional Parameters</title>
-<simpara>An optional formal parameter can be omitted when calling a function/method.
-An omitted parameter has the value <literal>undefined</literal>.
-In case the omitted parameter is variadic, the value is an empty array.</simpara>
-<simpara>Parameters can not be declared as optional explicitly.
-Instead, being optional is true when a parameter is declared as default or variadic.
-Note that any formal parameter that follows a default parameter is itself also a default thus an optional parameter.</simpara>
-</section>
-<section xml:id="Type_Modifiers_Default">
-<title>Default Parameters</title>
-<simpara>A default parameter value is specified for a parameter via an equals sign (<literal>=</literal>).
-If a caller doesn’t provide a value for the parameter, the default value is used.</simpara>
-<simpara>Default initializers of parameters are specified at a formal parameter of a function or method after the equal sign using an arbitrary initializer expression, such as <literal>var = "s"</literal>.
-However, this default initializer can be omitted.
-When a formal parameter has a declared type, the default initializer is specified at the end, such as: <literal>var : string = "s"</literal>.
-The initializer expression is only evaluated in case no actual argument is given for the formal parameter.
-Also, the initializer expression is evaluated when the actual argument value is <literal>undefined</literal>.</simpara>
-<simpara>Formal parameters become default parameters implicitly when they are preceded by an explicit default parameter.
-In such cases, the default initializer is <literal>undefined</literal>.</simpara>
-<requirement xml:id="IDE-14501">
-<title>Default parameters</title>
-<simpara>
-<anchor xml:id="Req-IDE-14501" xreflabel="[Req-IDE-14501]"/>
-<emphasis role="strong">Requirement: IDE-14501:</emphasis>
-<link linkend="Req-IDE-14501">Default parameters</link> (ver. 1)</simpara>
- <simpara>
-
-Any normal parameter which is preceded by a default parameter also becomes a default parameter.
-Its initializer is <literal>undefined</literal>.</simpara>
-</requirement>
-<simpara>When a method is overwritten, its default parameters are not part of the overwriting method.
-Consequently, initializers of default parameters in abstract methods are obsolete.</simpara>
-</section>
-<section xml:id="Type_Modifiers_Variadic">
-<title>Variadic</title>
-<simpara>Variadic parameters are also called <emphasis>rest parameters</emphasis>.
-Marking a parameter as variadic indicates that method accepts a variable number of parameters.
-A variadic parameter implies that the parameter is also optional as the cardinality is defined as <math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close="]" open="["><mrow><mn>0.</mn><mo>.</mo><mo>*</mo></mrow></mfenced></math>.
-No further parameter can be defined after a variadic parameter.
-When no argument is given for a variadic parameter, an empty array is provided when using the parameter in the body of the function or method.</simpara>
-<requirement xml:id="IDE-16">
-<title>Variadic and optional parameters</title>
-<simpara>
-<anchor xml:id="Req-IDE-16" xreflabel="[Req-IDE-16]"/>
-<emphasis role="strong">Requirement: IDE-16:</emphasis>
-<link linkend="Req-IDE-16">Variadic and optional parameters</link> (ver. 1)</simpara>
- <simpara>
-
-For a parameter <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi></math>, the following condition must hold:
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mo>→</mo><mi>p</mi><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></math>.</simpara>
-<simpara>A parameter can not be declared both variadic and with a default value.
-That is to say that one can either write <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi><mi>a</mi><mi>r</mi><mi>N</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo></math> (default) or <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mi>v</mi><mi>a</mi><mi>r</mi><mi>N</mi><mi>a</mi><mi>m</mi><mi>e</mi></math>, but not <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mi>v</mi><mi>a</mi><mi>r</mi><mi>N</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo></math>.</simpara>
-</requirement>
-<simpara>Declaring a variadic parameter of type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> causes the type of the method parameter to become <literal>Array<T></literal>.
-That is, declaring <literal>function(…​tags : string)</literal> causes <literal>tags</literal> to be an <literal>Array<string></literal> and not just a scalar <literal>string</literal> value.</simpara>
-<simpara>To make this work at runtime, the compiler will generate code that constructs the <literal>parameter</literal> from the <literal>arguments</literal> parameter explicitly passed to the function.</simpara>
-<requirement xml:id="IDE-17">
-<title>Variadic at Runtime</title>
-<simpara>
-<anchor xml:id="Req-IDE-17" xreflabel="[Req-IDE-17]"/>
-<emphasis role="strong">Requirement: IDE-17:</emphasis>
-<link linkend="Req-IDE-17">Variadic at Runtime</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>At runtime, a variadic parameter is never set to undefined.
-Instead, the array may be empty.
-This must be true even if preceding parameters are optional and no arguments are passed at runtime.</simpara>
-</requirement>
-<simpara>For more constraints on using the variadic modifier, see <xref linkend="_function-object-type"/>.</simpara>
-</section>
-</section>
-<section xml:id="_generator-functions">
-<title>Generator Functions</title>
-<simpara>Generators come together with the <literal>yield</literal> expression and can play three roles:
-the role of an iterator (data producer), of an observer (data consumer), and a combined role which is called coroutines.
-When calling a generator function or method, the returned generator object of type <literal>Generator<TYield,TReturn,TNext></literal> can be controlled by its methods
-(cf. [<link linkend="ECMA15a">ECMA15a(p.S14.4)</link>], also see [<link linkend="Kuizinas14a">Kuizinas14a</link>]).</simpara>
-<section xml:id="generator-functions-syntax">
-<title>Syntax</title>
-<simpara>Generator functions and methods differ from ordinary functions and methods only in the additional <literal>*</literal> symbol before the function or method name.
-The following syntax rules are extracted from the real syntax rules.
-They only display parts relevant to declaring a function or method as a generator.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">GeneratorFunctionDeclaration <Yield>:
- (declaredModifiers+=N4Modifier)*
- 'function' generator?='*'
- FunctionHeader<YieldIfGenerator,Generator=true>
- FunctionBody<Yield=true,Expression=false>
-;
-
-GeneratorFunctionExpression:
- 'function' generator?='*'
- FunctionHeader<YieldIfGenerator,Generator=true>
- FunctionBody<Yield=true,Expression=true>
-;
-
-GeneratorMethodDeclaration:
- annotations+=Annotation+ (declaredModifiers+=N4Modifier)* TypeVariables?
- generator?='*' NoLineTerminator LiteralOrComputedPropertyName<Yield>
- MethodParamsReturnAndBody<Generator=true></programlisting>
-</section>
-<section xml:id="generator-functions-semantics">
-<title>Semantics</title>
-<simpara>The basic idea is to make code dealing with Generators easier to write and more readable without changing their functionality.
-Take this example:</simpara>
-<example xml:id="ex:two-simple-generator-functions">
-<title>Two simple generator functions</title>
-<programlisting language="n4js" linenumbering="unnumbered">// explicit form of the return type
-function * countTo(iMax:int) : Generator<int,string,undefined> {
- for (int i=0; i<=iMax; i++)
- yield i;
- return "finished";
-}
-val genObj1 = countTo(3);
-val values1 = [...genObj1]; // is [0,1,2,3]
-val lastObj1 = genObj1.next(); // is {value="finished",done=true}
-
-// shorthand form of the return type
-function * countFrom(start:int) : int {
- for (int i=start; i>=0; i--)
- yield i;
- return finished;
-}
-val genObj2 = countFrom(3);
-val values2 = [...genObj2]; // is [3,2,1,0]
-val lastObj2 = genObj2.next(); // is {value="finished",done=true}</programlisting>
-<simpara>In the example above, two generator functions are declared.
-The first declares its return type explicitly whereas the second uses a shorthand form.</simpara>
-</example>
-<simpara>Generator functions and methods return objects of the type <literal>Generator<TYield,TReturn,TNext></literal> which is a subtype of the <literal>Iterable<TYield></literal> and <literal>Iterator<TYield></literal> interfaces.
-Moreover, it provides the methods <literal>throw(exception:any)</literal> and <literal>return(value:TNext?)</literal> for advanced control of the generator object.
-The complete interface of the generator class is given below.</simpara>
-<formalpara>
-<title>The generator class</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">public providedByRuntime interface Generator<out TYield, out TReturn, in TNext>
- extends Iterable<TYield>, Iterator<TYield> {
- public abstract next(value: TNext?): IteratorEntry<TYield>
- public abstract [Symbol.iterator](): Generator<TYield, TReturn, TNext>
- public abstract throw(exception: any): IteratorEntry<TYield>;
- public abstract return(value: TNext?): IteratorEntry<TReturn>;
-}</programlisting>
-</para>
-</formalpara>
-<requirement xml:id="IDE-14370">
-<title>Modifier <literal>*</literal></title>
-<simpara>
-<anchor xml:id="Req-IDE-14370" xreflabel="[Req-IDE-14370]"/>
-<emphasis role="strong">Requirement: IDE-14370:</emphasis>
-<link linkend="Req-IDE-14370">Modifier `pass:[*]`</link> (ver. 1)</simpara>
- <simpara>
-
-. <literal>*</literal> may be used on declared functions and methods, and for function expressions.
-. A function or method <emphasis>f</emphasis> with a declared return type <emphasis>R</emphasis> that is declared <literal>*</literal> has an actual return type of <literal>Generator<TYield,TReturn,TNext></literal>.
-. A generator function or method can have no declared return type, a shorthand form of a return type or an explicitly declared return type.
-.. The explicitly declared return type is of the form <literal>Generator<TYield,TReturn,TNext></literal> with the type variables:
-…​ <emphasis>TYield</emphasis> as the expected type of the yield expression argument,
-…​ <emphasis>TReturn</emphasis> as the expected type of the return expression, and
-…​ <emphasis>TNext</emphasis> as both the return type of the yield expression.
-.. The shorthand form only declares the type of <emphasis>TYield</emphasis> which implicitly translates to <literal>Generator<TYield,TReturn,any></literal> as the return type.
-…​ The type <emphasis>TReturn</emphasis> is inferred to either <literal>undefined</literal> or <literal>any</literal> from the body.
-…​ In case the declared type is <literal>void</literal>, actual return type evaluates to <literal>Generator<undefined,undefined,any></literal>.
-.. If no return type is declared, both <emphasis>TYield</emphasis> and <emphasis>TReturn</emphasis> are inferred from the body to either <literal>any</literal> or <literal>undefined</literal>. <emphasis>TNext</emphasis> is <literal>any</literal>.
-. Given a generator function or method <emphasis>f</emphasis> with an actual return type <literal>Generator<TYield,TReturn,TNext></literal>:
-.. all yield statements in <emphasis>f</emphasis> must have an expression of type <emphasis>TYield</emphasis>.
-.. all return statements in <emphasis>f</emphasis> must have an expression of type <emphasis>TReturn</emphasis>.
-. Return statements in generator functions or methods are always optional.</simpara>
-</requirement>
-<requirement xml:id="IDE-14371">
-<title>Modifier <literal>yield</literal> and <literal>yield*</literal></title>
-<simpara>
-<anchor xml:id="Req-IDE-14371" xreflabel="[Req-IDE-14371]"/>
-<emphasis role="strong">Requirement: IDE-14371:</emphasis>
-<link linkend="Req-IDE-14371">Modifier `yield` and `yield*`</link> (ver. 1)</simpara>
- <simpara>
-
-. <literal>yield</literal> and <literal>yield*</literal> may only be in body of generator functions or methods.
-. <literal>yield expr</literal> takes only expressions <emphasis>expr</emphasis> of type <emphasis>TYield</emphasis> in a generator function or methods with the actual type <literal>Generator<TYield,TReturn,TNext></literal>.
-. The return type of the <literal>yield</literal> expression is <emphasis>TNext</emphasis>.
-. <literal>yield* fg()</literal> takes only iterators of type <literal>Iterator<TYield></literal>, and generator functions or methods <emphasis>fg</emphasis> with the actual return type <literal>Generator<? extends TYield,? extends TReturn,? super TNext></literal>.
-. The return type of the <literal>yield*</literal> expression is <emphasis>any</emphasis>, since a custom iterator could return an entry <literal>{done=true,value}</literal> and any value for the variable <literal>value</literal>.</simpara>
-</requirement>
-<simpara>Similar to <literal>async</literal> functions, shorthand and explicit form <literal>* function():int{};</literal> and <literal>* function():Generator<int,TResult,any></literal> are equal,
-given that the inferred <emphasis>TResult</emphasis> of the former functions equals to <emphasis>TResult</emphasis> in the latter function).
-In other words, the return type of generator functions or methods is wrapped when it is not explicitly defined as <literal>Generator</literal> already.
-Thus, whenever a nested generator type is desired, it has to be defined explicitly.
-Consider the example below.</simpara>
-<formalpara>
-<title>Type variables with async methods.</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class C<T> {
- genFoo(): T{} // equals to genFoo(): Generator<T, undefined, any>;
- // note that TResult depends on the body of genFoo()
-}
-function fn(C<int> c1, C<Generator<int,any,any>> c2) {
- c1.genFoo(); // returns Generator<int, undefined, any>
- c2.genFoo(); // returns Generator<Generator<int,any,any>, undefined, any>
-}</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="_generator-arrow-functions">
-<title>Generator Arrow Functions</title>
-<simpara>As of now, generator arrow functions are not supported by EcmaScript 6 and also, the support is not planned.
-However, introducing generator arrow function in EcmaScript is still under discussion.
-For more information, please refer to <link xl:href="https://esdiscuss.org/topic/generator-arrow-functions">ESDiscuss.org</link> and <link xl:href="https://esdiscuss.org/topic/why-do-generator-expressions-return-generators">StackOverflow.com</link>.</simpara>
-</section>
-</section>
-<section xml:id="_arrow-function-expression">
-<title>Arrow Function Expression</title>
-<simpara>This is an ECMAScript 6 expression (see [<link linkend="ECMA15a">ECMA15a(p.S14.2)</link>]) for simplifying the definition of anonymous function expressions, a.k.a. lambdas or closures.
-The ECMAScript Specification calls this a function definition even though they may only appear in the context of expressions.</simpara>
-<simpara>Along with Assignments, Arrow function expressions have the least precedence, e.g. they serve as the entry point for the expression tree.</simpara>
-<simpara>Arrow function expressions can be considered syntactic window-dressing for old-school function expressions and therefore do not support the
-benefits regarding parameter annotations although parameter types may be given explicitly.
-The return type can be given as type hint if desired, but this is not mandatory (if left out, the return type is inferred).
-The notation <literal>@=></literal> stands for an async arrow function (<xref linkend="_asynchronous-arrow-functions"/>).</simpara>
-<section xml:id="arrow-function-expression-syntax">
-<title>Syntax</title>
-<simpara>The simplified syntax reads like this:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ArrowExpression returns ArrowFunction:
- =>(
- {ArrowFunction}
- (
- '('
- ( fpars+=FormalParameterNoAnnotations ( ',' fpars+=FormalParameterNoAnnotations )* )?
- ')'
- (':' returnTypeRef=TypeRef)?
- | fpars+=FormalParameterNoType
- )
- '=>'
- ) (
- (=> hasBracesAroundBody?='{' body=BlockMinusBraces '}') | body=ExpressionDisguisedAsBlock
- )
-;
-
-FormalParameterNoAnnotations returns FormalParameter:
- (declaredTypeRef=TypeRef variadic?='...'?)? name=JSIdentifier
-;
-FormalParameterNoType returns FormalParameter: name=JSIdentifier;
-
-BlockMinusBraces returns Block: {Block} statements+=Statement*;
-
-ExpressionDisguisedAsBlock returns Block:
- {Block} statements+=AssignmentExpressionStatement
-;
-
-AssignmentExpressionStatement returns ExpressionStatement: expression=AssignmentExpression;</programlisting>
-</section>
-<section xml:id="arrow-function-expression-semantics-and-type-inference">
-<title>Semantics and Type Inference</title>
-<simpara>Generally speaking, the semantics are very similar to the function
-expressions but the devil’s in the details:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>arguments</literal>: Unlike normal function expressions, an arrow function does not introduce an implicit <literal>arguments</literal> variable (<xref linkend="_arguments-object"/>),
-therefore any occurrence of it in the arrow function’s body has always the same binding as an occurrence of <literal>arguments</literal> in the lexical context enclosing the arrow function.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>this</literal>: An arrow function does not introduce a binding of its own for the <literal>this</literal> keyword. That explains why uses in the body of arrow function have the same meaning as occurrences in the enclosing lexical scope.
-As a consequence, an arrow function at the top level has both usages of <literal>arguments</literal> and <literal>this</literal> flagged as error (the outer lexical context doesn’t provide definitionsfor them).</simpara>
-</listitem>
-<listitem>
-<simpara><literal>super</literal>: As with function expressions in general, whether of the arrow variety or not, the usage of <literal>super</literal> isn’t allowed in the body of arrow functions.</simpara>
-</listitem>
-</itemizedlist>
-<requirement xml:id="IDE-84">
-<title>No This in Top Level Arrow Function in N4JS Mode</title>
-<simpara>
-<anchor xml:id="Req-IDE-84" xreflabel="[Req-IDE-84]"/>
-<emphasis role="strong">Requirement: IDE-84:</emphasis>
-<link linkend="Req-IDE-84">No This in Top Level Arrow Function in N4JS Mode</link> (ver. 1)</simpara>
- <simpara>
-
-In N4JS, a top-level arrow function can’t refer to <literal>this</literal> as there’s no outer lexical context that provides a binding for it.</simpara>
-</requirement>
-<requirement xml:id="IDE-85">
-<title>No Arguments in Top Level Arrow Function</title>
-<simpara>
-<anchor xml:id="Req-IDE-85" xreflabel="[Req-IDE-85]"/>
-<emphasis role="strong">Requirement: IDE-85:</emphasis>
-<link linkend="Req-IDE-85">No Arguments in Top Level Arrow Function</link> (ver. 1)</simpara>
- <simpara>
-
-In N4JS, a top-level arrow function can’t include usages of <literal>arguments</literal> in its body, again because of the missing binding for it.</simpara>
-</requirement>
-</section>
-</section>
-</section>
-<section xml:id="_ecmascript-proposals-function-definition" role="language-n4js">
-<title>ECMAScript Proposals Function Definition</title>
-<section xml:id="_asynchronous-functions">
-<title>Asynchronous Functions</title>
-<simpara>To improve language-level support for asynchronous code, there exists an ECMAScript proposal <footnote><simpara>see <link xl:href="http://tc39.github.io/ecmascript-asyncawait/">http://tc39.github.io/ecmascript-asyncawait/</link></simpara></footnote> based on Promises which are provided by ES6 as built-in types.
-N4JS implements this proposal.
-This concept is supported for declared functions and methods (<xref linkend="_asynchronous-methods"/>) as well
-as for function expressions and arrow functions (<xref linkend="_asynchronous-arrow-functions"/>).</simpara>
-<section xml:id="asynchronous-functions-syntax">
-<title>Syntax</title>
-<simpara>The following syntax rules are extracted from the real syntax rules.
-They only display parts relevant to declaring a function or method as
-asynchronous.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">AsyncFunctionDeclaration <Yield>:
- (declaredModifiers+=N4Modifier)*
- declaredAsync?='async' NoLineTerminator 'function'
- FunctionHeader<Yield,Generator=false>
- FunctionBody<Yield=false,Expression=false>
-;
-
-AsyncFunctionExpression:
- declaredAsync?='async' NoLineTerminator 'function'
- FunctionHeader<Yield=false,Generator=false>
- FunctionBody<Yield=false,Expression=true>
-;
-
-AsyncArrowExpression <In, Yield>:
- declaredAsync?='async' NoLineTerminator '('
- (fpars+=FormalParameter<Yield>
- (',' fpars+=FormalParameter<Yield>)*)?
- ')' (':' returnTypeRef=TypeRef)? '=>'
- ( '{' body=BlockMinusBraces<Yield> '}'
- | body=ExpressionDisguisedAsBlock<In>
- )
-;
-
-AsyncMethodDeclaration:
- annotations+=Annotation+ (declaredModifiers+=N4Modifier)* TypeVariables?
- declaredAsync?='async' NoLineTerminator LiteralOrComputedPropertyName<Yield>
- MethodParamsReturnAndBody</programlisting>
-<simpara>’async’ is not a reserved word in ECMAScript and it can therefore be
-used either as an identifier or as a keyword, depending on the context.
-When used as a modifier to declare a function as asynchronous, then
-there must be no line terminator after the <literal>async</literal> modifier. This enables the
-parser to distinguish between using <literal>async</literal> as an identifier reference and a
-keyword, as shown in the next example.</simpara>
-<example>
-<title>Async as keyword and identifier</title>
-<programlisting language="n4js" linenumbering="unnumbered">async <co xml:id="CO2-1"/>
-function foo() {}
-// vs
-async function bar(); <co xml:id="CO2-2"/></programlisting>
-<calloutlist>
-<callout arearefs="CO2-1">
-<para>In this snippet, the <literal>async</literal> on line 1 is an identifier reference (referencing a
-variable or parameter) and the function defined on line 2 is a
-non-asynchronous function. The automatic semicolon insertion adds a
-semicolon after the reference on line 1.</para>
-</callout>
-<callout arearefs="CO2-2">
-<para>In contrast, <literal>async</literal> on line 4 is recognized as a modifier declaring the function as asynchronous.</para>
-</callout>
-</calloutlist>
-</example>
-</section>
-<section xml:id="asynchronous-functions-semantics">
-<title>Semantics</title>
-<simpara>The basic idea is to make code dealing with Promises easier to write and
-more readable without changing the functionality of Promises. Take this
-example:</simpara>
-<formalpara>
-<title>A simple asynchronous function using async/await.</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">// some asynchronous legacy API using promises
-interface DB {}
-interface DBAccess {
- getDataBase(): Promise<DB,?>
- loadEntry(db: DB, id: string): Promise<string,?>
-}
-
-var access: DBAccess;
-
-// our own function using async/await
-async function loadAddress(id: string) : string {
- try {
- var db: DB = await access.getDataBase();
- var entry: string = await access.loadEntry(db, id);
- return entry.address;
- }
- catch(err) {
- // either getDataBase() or loadEntry() failed
- throw err;
- }
-}</programlisting>
-</para>
-</formalpara>
-<simpara>The modifier <literal>async</literal> changes the return type of <literal>loadAddress()</literal> from <literal>string</literal> (the declared return type) to <literal>Promise<string,?></literal> (the actual return type).
-For code inside the function, the return type is still <literal>string</literal>:
-the value in the return statement of the last line will be wrapped in a Promise.
-For client code outside the function and in case of recursive invocations, the return type is <literal>Promise<string,?></literal>.
-To raise an error, simply throw an exception, its value will become the error value of the returned Promise.</simpara>
-<simpara>If the expression after an <literal>await</literal> evaluates to a <literal>Promise</literal>, execution of the enclosing asynchronous function will be suspended until either a success value is available
-(which will then make the entire await-expression evaluate to this success value and continue execution)
-or until the Promise is rejected (which will then cause an exception to be thrown at the location of the await-expression).
-If, on the other hand, the expression after an <literal>await</literal> evaluates to a non-promise, the value will be simply passed through.
-In addition, a warning is shown to indicate the unnecessary <literal>await</literal> expression.</simpara>
-<simpara>Note how method <literal>loadAddress()</literal> above can be implemented without any explicit references to the built-in type Promise.
-In the above example we handle the errors of the nested asynchronous calls to <literal>getDataBase()</literal> and <literal>loadEntry()</literal> for demonstration purposes only;
-if we are not interested in the errors we could simply remove the try/catch block and any errors would be forwarded to the caller of <literal>loadAddress()</literal>.</simpara>
-<simpara>Invoking an async function commonly adopts one of two forms:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>var p: Promise<successType,?> = asyncFn()</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>await asyncFn()</literal></simpara>
-</listitem>
-</itemizedlist>
-<simpara>These patterns are so common that a warning is available whenever both</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>Promise</literal> is omitted as expected type; and</simpara>
-</listitem>
-<listitem>
-<simpara><literal>await</literal> is also omitted.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The warning aims at hinting about forgetting to wait for the result, while remaining non-noisy.</simpara>
-<requirement xml:id="IDE-86">
-<title>Modifier <literal>async</literal> and <literal>await</literal></title>
-<simpara>
-<anchor xml:id="Req-IDE-86" xreflabel="[Req-IDE-86]"/>
-<emphasis role="strong">Requirement: IDE-86:</emphasis>
-<link linkend="Req-IDE-86">Modifier `async` and `await`</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>async</literal> may be used on declared functions and methods as well as for function expressions and arrow functions.</simpara>
-</listitem>
-<listitem>
-<simpara>A function or method that is declared <literal>async</literal> can have no declared return type, a shorthand form of a return type or an explicitly declared return type.</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>The explicitly declared return type is of the form <literal>Promise<R,E></literal> where <emphasis>R</emphasis> is the type of all return statements in the body, and E is the type of exceptions that are thrown in the body.</simpara>
-</listitem>
-<listitem>
-<simpara>The shorthand form only declares the type of <emphasis>R</emphasis> which implicitly translates to <literal>Promise<R,?></literal> as the actual return type.</simpara>
-</listitem>
-<listitem>
-<simpara>In case no return type is declared, the type <emphasis>R</emphasis> of <literal>Promise<R,?></literal> is inferred from the body.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>A function or method <emphasis>f</emphasis> with a declared return type <emphasis>R</emphasis> that is declared <literal>async</literal> has an actual return type of</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara><literal>R</literal> if <emphasis>R</emphasis> is a subtype of <literal>Promise<?,?></literal>,</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Promise<undefined,?></literal> if <emphasis>R</emphasis> is type <literal>void</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Promise<R,?></literal> in all other cases (i.e. the declared return type <emphasis>R</emphasis> is being wrapped in a <literal>Promise</literal>).</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Return type inference is only performed when no return type is declared.</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>The return type <literal>R</literal> of <literal>Promise<R,?></literal> is inferred either as <literal>void</literal> or as <literal>any</literal>.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>Given a function or method <emphasis>f</emphasis> that is declared <literal>async</literal> with a declared return type <emphasis>R</emphasis>, or with a declared return type <literal>Promise<R,?></literal>,
-all return statements in <emphasis>f</emphasis> must have an expression of type <emphasis>R</emphasis> (and not of type <literal>Promise<R,?></literal>).</simpara>
-</listitem>
-<listitem>
-<simpara><literal>await</literal> can be used in expressions directly enclosed in an async function, and behaves like a unary operator with the same precedence as <literal>yield</literal> in ES6.</simpara>
-</listitem>
-<listitem>
-<simpara>Given an expression <emphasis>expr</emphasis> of type
-<emphasis>T</emphasis>, the type of (<literal>await</literal> <emphasis>expr</emphasis>) is inferred to <emphasis>T</emphasis> if
-<emphasis>T</emphasis> is not a Promise, or it is inferred to <emphasis>S</emphasis> if
-<emphasis>T</emphasis> is a Promise with a success value of type
-<emphasis>S</emphasis>, i.e. <emphasis>T <: Promise<S,?></emphasis> .</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>In other words, the return type <emphasis>R</emphasis> of <literal>async</literal> functions and methods will always be wrapped to <literal>Promise<R,?></literal> unless <emphasis>R</emphasis> is a <literal>Promise</literal> already.
-As a consequence, nested <literal>Promise</literal>s as a return type of a async function or method have to be stated explicitly like <literal>Promise<Promise<R,?>,?></literal>.</simpara>
-<simpara>When a type variable <literal>T</literal> is used to define the the return type of an async function or method, it will always be wrapped.
-Consider the example below.</simpara>
-<example>
-<title>Type variables with async methods.</title>
-<programlisting language="n4js" linenumbering="unnumbered">interface I<T> {
- async foo(): T; // amounts to foo(): Promise<T,?>
-}
-function snafu(i1: I<int>, i2: I<Promise<int,?>>) {
- i1.foo(); // returns Promise<int,?>
- i2.foo(); // returns Promise<Promise<int,?>,?>
-}</programlisting>
-</example>
-</section>
-<section xml:id="_asynchronous-arrow-functions">
-<title>Asynchronous Arrow Functions</title>
-<simpara>An <literal>await</literal> expression is allowed in the body of an async arrow function but not
-in the body of a non-async arrow function. The semantics here are
-intentional and are in line with similar constraint for function
-expressions.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_n4js-extended-function-definition" role="language-n4js">
-<title>N4JS Extended Function Definition</title>
-<section xml:id="_generic-functions">
-<title>Generic Functions</title>
-<simpara>A generic function is a function with a list of generic type parameters.
-These type parameters can be used in the function signature to declare the types of formal parameters and the return type.
-In addition, the type parameters can be used in the function body, for example when declaring the type of a local variable.</simpara>
-<simpara>In the following listing, a generic function <literal>foo</literal> is defined that has two type parameters <literal>S</literal> and <literal>T</literal>.
-Thereby <literal>S</literal> is used as to declare the parameter type <literal>Array<S></literal> and <literal>T</literal> is used as the return type and to construct the returned value in the function body.</simpara>
-<formalpara>
-<title>Generic Function Definition</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">function <S,T> foo(s: Array<S>): T { return new T(s); }</programlisting>
-</para>
-</formalpara>
-<simpara>If a generic type parameter is not used as a formal parameter type or
-the return type, a warning is generated.</simpara>
-</section>
-<section xml:id="_promisifiable-functions">
-<title>Promisifiable Functions</title>
-<simpara>In many existing libraries, which have been developed in pre-ES6-promise-API times, callback methods are used for asynchronous behavior.
-An asynchronous function follows the following conventions:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">'function' name '(' arbitraryParameters ',' callbackFunction ')'</programlisting>
-<simpara>Usually the function returns nothing (<literal>void</literal>).
-The callback function usually takes two arguments,in which the first is an error object and the other is the result value of the asynchronous operation.
-The callback function is called from the asynchronous function, leading to nested function calls (aka ’callback hell’).</simpara>
-<simpara>In order to simplify usage of this pattern, it is possible to mark such a function or method as <literal>@Promisifiable</literal>.
-It is then possible to ’promisify’ an invocation of this function or method, which means no callback function argument has to be provided and a will be returned.
-The function or method can then be used as if it were declared with <literal>async</literal>.
-This is particularly useful in N4JS definition files (.n4jsd) to allow using an existing callback-based API from N4JS code with the more convenient <literal>await</literal>.</simpara>
-<example>
-<title>Promisifiable</title>
-<simpara>Given a function with an N4JS signature</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">f(x: int, cb: {function(Error, string)}): void</programlisting>
-<simpara>This method can be annotated with <literal>Promisifiable</literal> as follows:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">@Promisifiable f(x: int, cb: {function(Error, string)}): void</programlisting>
-<simpara>With this annotation, the function can be invoked in four different
-ways:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">f(42, function(err, result1) { /* ... */ }); // traditional
-var promise: Promise<string,Error> = @Promisify f(42); // promise
-var result3: string = await @Promisify f(42); // long
-var result4: string = await f(42); // short</programlisting>
-<simpara>The first line is only provided for completeness and shows that a promisifiable function can still be used in the ordinary way by providing a callback - no special handling will occur in this case.
-The second line shows how <literal>f</literal> can be promisified using the <literal>@Promisify</literal> annotation - no callback needs to be provided and instead, a <literal>Promise</literal> will be returned.
-We can either use this promise directly or immediately <literal>await</literal> on it, as shown in line 3.
-The syntax shown in line 4 is merely shorthand for <literal>await @Promisify</literal>, i.e. the annotation is optional after <literal>await</literal>.</simpara>
-</example>
-<requirement xml:id="IDE-87">
-<title>Promisifiable</title>
-<simpara>
-<anchor xml:id="Req-IDE-87" xreflabel="[Req-IDE-87]"/>
-<emphasis role="strong">Requirement: IDE-87:</emphasis>
-<link linkend="Req-IDE-87">Promisifiable</link> (ver. 1)</simpara>
- <simpara>
-
-A function or method <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> can be annotated with <literal>@Promisifiable</literal> if and only if the following constraints hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Last parameter of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> is a function (the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>a</mi><mi>l</mi><mi>l</mi><mi>b</mi><mi>a</mi><mi>c</mi><mi>k</mi></math>).</simpara>
-</listitem>
-<listitem>
-<simpara>The <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>a</mi><mi>l</mi><mi>l</mi><mi>b</mi><mi>a</mi><mi>c</mi><mi>k</mi></math> has a signature of</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>{function(E, T0, T1, …​, Tn): V}</literal>, or</simpara>
-</listitem>
-<listitem>
-<simpara><literal>{function(T0, T1, …​, Tn): V}</literal></simpara>
-<simpara>in which <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math> is type <literal>Error</literal> or a subtype thereof, <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mn>0</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></math> are arbitrary types except or its subtypes.
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math>, if given, is then the type of the error value, and <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mn>0</mn></msub><mo>,</mo><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>,</mo><msub><mi>T</mi><mi>n</mi></msub></math> are the types of the success values of the asynchronous operation.<?asciidoc-br?>
-Since the return value of the synchronous function call is not available when using <literal>@Promisify</literal>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>V</mi></math> is recommended to be <literal>void</literal>, but it can be any type.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>The callback parameter may be optional.<footnote><simpara>Even in this case, the function will actually be called with the callback method which is then created by the transpiler. However, the callback is not given in the N4JS code).</simpara></footnote></simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>According to <xref linkend="Req-IDE-87"/>, a promisifiable function or method may or may not have a non-void return type, and that only the first parameter of the callback is allowed to be of type <literal>Error</literal>, all other parameters must be of other types.</simpara>
-<requirement xml:id="IDE-88">
-<title>@Promisify and await with promisifiable functions</title>
-<simpara>
-<anchor xml:id="Req-IDE-88" xreflabel="[Req-IDE-88]"/>
-<emphasis role="strong">Requirement: IDE-88:</emphasis>
-<link linkend="Req-IDE-88">@Promisify and await with promisifiable functions</link> (ver. 1)</simpara>
- <simpara>
-
-A promisifiable function <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> with one of the two valid
-signatures given in <xref linkend="Req-IDE-87"/> can be promisified with <literal>Promisify</literal> or
-used with <literal>await</literal>, if and only if the following constraints hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Function <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> must be annotated with <literal>@Promisifiable</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Using <literal>@Promisify f()</literal> without <literal>await</literal> returns a promise of type <literal>Promise<S,F></literal> where</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> is <literal>IterableN<T0,…​,Tn></literal> if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mo>≥</mo><mn>2</mn></math>, <literal>T</literal> if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mo>=</mo><mn>1</mn></math>, and <literal>undefined</literal> if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mo>=</mo><mn>0</mn></math>.</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> is <literal>E</literal> if given, <literal>undefined</literal> otherwise.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>Using <literal>await @Promisify f()</literal> returns a value of type <literal>IterableN<T0,…​,Tn></literal> if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mo>≥</mo><mn>2</mn></math>, of type <literal>T</literal> if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mo>=</mo><mn>1</mn></math>, and of type <literal>undefined</literal> if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mo>=</mo><mn>0</mn></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>In case of using an <literal>await</literal>, the annotation can be omitted.<?asciidoc-br?>
-I.e., <literal>await @Promisify f()</literal> is equivalent to <literal>await f()</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Only call expressions using f as target can be promisified, in other
-words this is illegal:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var pf = @Promisify f; // illegal code!</programlisting>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_conversions-and-reflection">
-<title>Conversions and Reflection</title>
-<section xml:id="_autoboxing-and-coercing" role="language-n4js">
-<title>Autoboxing and Coercing</title>
-<simpara>Coercing is the ability to implicitly cast one (primitive) type to another.
-Autoboxing is a special kind of coercing in that is the ability to automatically convert a primitive value type, such as <literal>string</literal>, <literal>number</literal>, or <literal>boolean</literal>,
-to its corresponding Object type version <literal>String</literal>, <literal>Number</literal>, <literal>Boolean</literal>.
-The capital letters in the latter are an essential distinction.</simpara>
-<simpara>Conversion between primitives and object-representations of a datatype are not automatic in N4JS. Only in the cases of object-method invocations on a primitive type
-(for <literal>string</literal> to call <literal>"abc".length</literal>, for example) automatic conversion is applied.</simpara>
-<simpara>Note that N4JS specific primitive types <literal>pathselector</literal> and <literal>i18nkey</literal> are handled similarly to <literal>string</literal>.</simpara>
-<section xml:id="_coercing">
-<title>Coercing</title>
-<simpara>In [<link linkend="ECMA11a">ECMA11a</link>], coercing is defined by means of the abstract specification method <literal>ToPrimitive</literal> [<link linkend="ECMA11a">ECMA11a(p.S9.1)</link>], also see [<link linkend="ECMA11a">ECMA11a(p.S9.10)</link>]).
-Other conversions, such as <literal>ToNumber</literal>, are not directly supported but reflected in the typing rules of expressions.</simpara>
-<simpara>We express absence of automatic coercion here by means of subtype
-relations:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>Boolean</mtext></mstyle><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>boolean</mtext></mstyle></mrow></mfrac><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>boolean</mtext></mstyle><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>Boolean</mtext></mstyle></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>Number</mtext></mstyle><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>Number</mtext></mstyle></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>String</mtext></mstyle><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle><mspace width="1.0mm"/><mo>≮</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>String</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-<simpara>and for the N4JS specific types:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>pathSelector</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mo>></mo><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>i18nKey</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac></math></simpara>
-<simpara>If a conversion between primitive and object type is desired, we require the user of N4JS to actively convert the values.
-The reason for that is the notably different behavior of object- and primitive-variants of a type in expression evaluation:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var bool: boolean = false;
-var Bool: Boolean = new Boolean( false );
-
-console.log( bool ? "true" : "false"); // prints "false"
-console.log( Bool ? "true" : "false"); // prints "true"!</programlisting>
-<simpara>Conversion between a primitive type to its object-variant is achieved by the <literal>new</literal> operator.
-The <literal>valueOf()</literal> method converts the object-variant back to a primitive value.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">// objects from literals:
-var bo: Boolean = new Boolean( true ); // typeof bo: object
-var no: Number = new Number( 42 ); // typeof no: object
-var so: String = new String( "foo" ); // typeof so: object
-
-// to primitive
-var b: boolean = bo.valueOf(); // typeof b: boolean -- true
-var n: number = no.valueOf(); // typeof n: number -- 42
-var s: string = so.valueOf(); // typeof s: string -- "foo"
-
-// to object-type
-bo = new Boolean( b );
-no = new Number( n );
-so = new String( s );</programlisting>
-<simpara>Conversion of variables of type <literal>Object</literal> or from one primitive type to another is expressed in terms of typing rules for expressions.
-That is, it is not possible to convert any <literal>Object</literal> to a primitive in general, but it is possible to do so in the context of certain expressions such as additive operator.
-The applied conversions are described in <xref linkend="_auto-conversion-of-class-instances"/></simpara>
-</section>
-<section xml:id="_autoboxing-of-primitives">
-<title>Autoboxing of Primitives</title>
-<simpara>In [<link linkend="ECMA11a">ECMA11a</link>], autoboxing is defined by <literal>ToObject</literal> [<link linkend="ECMA11a">ECMA11a(p.S9.9)</link>].</simpara>
-<simpara>Autoboxing is not directly supported in N4JS. Instead, primitive types virtually have the same members as their corresponding object types.
-It is then possible to use the Autoboxing feature when calling a member.
-In general, Autoboxing is only supported for accessing built-in read-only (immutable) properties.
-For example, <literal>"some string value".split(" ");</literal> is supported but <literal>"some string value".foo=1;</literal> will be rejected as String does not allow properties to be added (cf. <literal>String</literal> vs. <literal>String+</literal>, see <xref linkend="_dynamic"/>).</simpara>
-<simpara>Autoboxing often leads to problems, in particular in combination with dynamic types – this is why it is not directly supported in N4JS.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var s: String+ = "Hello"; <co xml:id="CO3-1"/>
-
-s.prop = 1;
-console.log(s.prop); <co xml:id="CO3-2"/></programlisting>
-<calloutlist>
-<callout arearefs="CO3-1">
-<para>will produce an error to prevent the following scenario:</para>
-</callout>
-<callout arearefs="CO3-2">
-<para>prints "undefined"</para>
-</callout>
-</calloutlist>
-</section>
-<section xml:id="_autoboxing-of-function-expressions-and-declarations">
-<title>Autoboxing of Function Expressions and Declarations</title>
-<simpara>Function expressions and declarations always define an object of type <literal>Function</literal>, thus coercing or Autoboxing is not required in case of functions:</simpara>
-<simpara>It is always possible to use a function expression where a <literal>Function</literal> is required, and to use an object of type <literal>Function</literal> where a function expression is expected.
-This is only possible if the function signatures are subtype-compatible, see <xref linkend="_function-type"/> for details.</simpara>
-<simpara>Still, it is always possible to call members of <literal>Function</literal>, e.g., <literal>function(){}.length()</literal>.</simpara>
-</section>
-</section>
-<section xml:id="_auto-conversion-of-objects" role="language-n4js">
-<title>Auto-Conversion of Objects</title>
-<section xml:id="_auto-conversion-of-class-instances">
-<title>Auto-Conversion of Class Instances</title>
-<simpara>All classes defined in N4JS modules implicitly subclass <literal>N4Object</literal>, which is a plain JavaScript Object type.
-The same auto-conversion rules defined for JavaScript <literal>Object</literal> therefore apply to <literal>N4Object</literal> instances as well.</simpara>
-<simpara>The basic conversion uses the abstract JavaScript function <literal>ToPrimitive</literal> [<link linkend="ECMA11a">ECMA11a(p.S9.1)</link>], which relays on the specification method <literal>Object</literal> [<link linkend="ECMA11a">ECMA11a(p.S8.12.8)</link>].
-<literal>DefaultValue</literal> calls <literal>valueOf</literal> or <literal>toString</literal> methods if they are defined by the class (in the <literal>methods</literal>-builder).</simpara>
-<simpara>Note that according to the [<link linkend="ECMA11a">ECMA11a</link>], in most cases, objects are first converted into primitives.
-That is, in most cases, no extra hint is passed to <literal>DefaultValue</literal>. Thus <literal>valueOf</literal> usually takes precedence over toString as demonstrated in the following example:</simpara>
-<example>
-<title>Auto-Conversion</title>
-<simpara>Assume some classes and corresponding instances defined as follows:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {}
-class B{
- @Override public toString(): string { return "MyB"}
-}
-class C{
- @Override public valueOf(): any { return 10}
-}
-class D{
- @Override public toString(): string { return "MyD"}
- @Override public valueOf(): any { return 20}
-}
-var a = new A(), b = new B(), c = new C(), d = new D();</programlisting>
-<simpara>Instances of these classes will be converted as demonstrated as follows:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">console.log(a+""); // [object Object]
-console.log(a+1); // [object Object]1
-
-console.log(""+b+""); // MyB
-console.log(1+b+1); // 1MyB1
-
-console.log(c+""); // 10
-console.log(c+1); // 11
-
-console.log(d+""); // 20
-console.log(d+1); // 21</programlisting>
-</example>
-<section xml:id="_auto-conversion-of-interface-instances">
-<title>Auto-Conversion of Interface Instances</title>
-<simpara>Instances of interfaces actually are instances of classes at runtime.
-The auto-conversion rules described in <xref linkend="_auto-conversion-of-class-instances"/> are applied to instances declared as instances of interfaces as well.</simpara>
-</section>
-</section>
-<section xml:id="_auto-conversion-of-enum-literals">
-<title>Auto-Conversion of Enum Literals</title>
-<simpara>Enumeration values are objects and thus follow the behavior for ECMAScript <literal>Object</literal> and <literal>Function</literal>.
-They have a custom <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>o</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>n</mi><mi>g</mi></math> method which returns the name of the enumeration value.</simpara>
-</section>
-</section>
-<section xml:id="_type-cast-and-type-check" role="language-n4js">
-<title>Type Cast and Type Check</title>
-<section xml:id="_type-cast">
-<title>Type Cast</title>
-<literallayout class="monospaced">(IDEBUG-56): Casting to TypeVars</literallayout>
-<simpara>Type casts are expressed with the cast expression (<literal>as</literal>), see <xref linkend="_cast-as-expression"/> for details.</simpara>
-<simpara>We first define helper rules for the type cast constraints as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∈</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>TEnum</mtext></mstyle><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle><mstyle mathvariant="monospace"><mtext>Primitive</mtext></mstyle><mstyle mathvariant="monospace"><mtext>ObjectType</mtext></mstyle></mfenced></mrow><mrow><mi>i</mi><mi>s</mi><mi>C</mi><mi>P</mi><mi>O</mi><mi>E</mi><mfenced close=")" open="("><mi>T</mi></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>μ</mi><mi>T</mi><mo>∈</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>ClassifierType</mtext></mstyle><mstyle mathvariant="monospace"><mtext>TypeType</mtext></mstyle></mfenced><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><mrow><mi>T</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></mrow></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>TypeVariable</mtext></mstyle></mrow><mrow><mi>i</mi><mi>s</mi><mi>C</mi><mi>P</mi><mi>O</mi><mi>E</mi><mfenced close=")" open="("><mi>T</mi></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∈</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>Interface</mtext></mstyle></mfenced></mrow><mrow><mi>i</mi><mi>s</mi><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mfenced close=")" open="("><mi>T</mi></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>TypeVariable</mtext></mstyle><mo>∧</mo><mi>T</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi><mo>≠</mo><mi>∅</mi></mrow><mrow><mi>i</mi><mi>s</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>V</mi><mi>a</mi><mi>r</mi><mfenced close=")" open="("><mi>T</mi></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∈</mo><mfenced close="}" open="{"><mrow><mi> </mi><mstyle mathvariant="monospace"><mtext>TEnum</mtext></mstyle></mrow><mstyle mathvariant="monospace"><mtext>Primitive</mtext></mstyle></mfenced><mo>∨</mo><mfenced close="}" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle><mo>∧</mo><mi>T</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>t</mi><mi>e</mi><mi>n</mi><mi>s</mi><mi>i</mi><mi>b</mi><mi>i</mi><mi>l</mi><mi>i</mi><mi>t</mi><mi>y</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>final</mtext></mstyle></mrow></mfenced><mo>)</mo></mrow><mrow><mi>i</mi><mi>s</mi><mi>F</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mi>B</mi><mi>y</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mfenced close=")" open="("><mi>T</mi></mfenced></mrow></mfrac></mtd></mtr></mtable></math>
-<requirement xml:id="IDE-89">
-<title>Cast Validation At Compile Time</title>
-<simpara>
-<anchor xml:id="Req-IDE-89" xreflabel="[Req-IDE-89]"/>
-<emphasis role="strong">Requirement: IDE-89:</emphasis>
-<link linkend="Req-IDE-89">Cast Validation At Compile Time</link> (ver. 1)</simpara>
- <simpara>
-
-Given a type cast expression <literal>e</literal> in which
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>:</mi><mi>S</mi></math> and and target type <literal>T</literal>, the
-following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>T</literal> must be a classifier, enum, primitive, function type expression, classifier type, type variable, union or intersection type:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∈</mo><mspace width="3.0mm"/><mrow><mo>{</mo><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>Interface</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>Enum</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>Primitive</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>ObjectType</mtext></mstyle><mo>,</mo></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mspace width="3.0mm"/><mstyle mathvariant="monospace"><mtext>FunctionTypeExpression</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>ClassifierType</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>TypeVariable</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>Union</mtext></mstyle><mo>,</mo><mstyle mathvariant="monospace"><mtext>Intersection</mtext></mstyle><mo>}</mo></mrow></math></simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>S</literal> is a subtype of <literal>T</literal>, the cast is unnecessary and a warning will be generated.</simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>S</literal> and <literal>T</literal> are classes, enums or primitive types, then <literal>T</literal> must be a subtype of <literal>S</literal>.
-This is also true if <literal>T</literal> is an interface and the type of <literal>S</literal> cannot have subtypes, or vice versa.</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>(</mo><mi>i</mi><mi>s</mi><mi>C</mi><mi>P</mi><mi>O</mi><mi>E</mi><mfenced close=")" open="("><mi>T</mi></mfenced></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><mo>∧</mo><mrow><mo>(</mo><mi>i</mi><mi>s</mi><mi>C</mi><mi>P</mi><mi>O</mi><mi>E</mi><mfenced close=")" open="("><mi>S</mi></mfenced></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mspace width="4.0em"/><mo>∨</mo><mfenced close=")" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Intersection</mtext></mstyle><mo>∧</mo><mo>∃</mo><msup><mi>S</mi><mi>'</mi></msup><mo>∈</mo><mi>S</mi><mi>:</mi><mi>i</mi><mi>s</mi><mi>C</mi><mi>P</mi><mi>O</mi><mi>E</mi><mfenced close=")" open="("><msup><mi>S</mi><mi>'</mi></msup></mfenced></mrow></mfenced><mo>)</mo></mrow></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∨</mo><mfenced close=")" open="("><mrow><mi>i</mi><mi>s</mi><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∧</mo><mi>i</mi><mi>s</mi><mi>F</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mi>B</mi><mi>y</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mfenced close=")" open="("><mi>S</mi></mfenced></mrow></mfenced></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>∨</mo><mfenced close=")" open="("><mrow><mi>i</mi><mi>s</mi><mi>F</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mi>B</mi><mi>y</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∧</mo><mi>i</mi><mi>s</mi><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mfenced close=")" open="("><mi>S</mi></mfenced></mrow></mfenced><mo>)</mo></mrow><mo>→</mo><mi>Γ</mi><mo>⊢</mo><mi>T</mi><mo><</mo><mi>:</mi><mi>S</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>S</literal> is a class, enum or primitive type and <literal>T</literal> is a type-variable, then for each given boundary <math xmlns="http://www.w3.org/1998/Math/MathML"><msubsup><mi>T</mi><mi>i</mi><mrow><mi>u</mi><mi>p</mi></mrow></msubsup></math> of <literal>T</literal>
-of type class, enum or primitive <literal>S</literal> must be a member of the type hierarchy: <footnote><simpara><literal>i</literal> iterates over all boundaries</simpara></footnote></simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close=")" open="("><mrow><mi>i</mi><mi>s</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>V</mi><mi>a</mi><mi>r</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∧</mo><mi>i</mi><mi>s</mi><mi>C</mi><mi>P</mi><mi>O</mi><mi>E</mi><mfenced close=")" open="("><mi>S</mi></mfenced></mrow></mfenced></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>→</mo><msub><mo>∀</mo><mrow><msubsup><mi>T</mi><mi>i</mi><mrow><mi>u</mi><mi>p</mi></mrow></msubsup><mo>∈</mo><mi>T</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>B</mi><mi>o</mi><mi>u</mi><mi>n</mi><mi>d</mi><mi>s</mi></mrow></msub><mrow><mo>(</mo><mi>i</mi><mi>s</mi><mi>C</mi><mi>P</mi><mi>O</mi><mi>E</mi><mfenced close=")" open="("><msubsup><mi>T</mi><mi>i</mi><mrow><mi>u</mi><mi>p</mi></mrow></msubsup></mfenced><mo>→</mo><mi>Γ</mi><mo>⊢</mo><mrow><mo>(</mo><mrow><mrow><msubsup><mi>T</mi><mi>i</mi><mrow><mi>u</mi><mi>p</mi></mrow></msubsup><mo><</mo><mi>:</mi><mi>S</mi><mo>∨</mo><msubsup><mi>T</mi><mi>i</mi><mrow><mi>u</mi><mi>p</mi></mrow></msubsup><mi>:</mi><mo>></mo><mi>S</mi><mo>)</mo></mrow><mo>)</mo></mrow></mrow></mrow></math></simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>S</literal> is a union or intersection type, then the type cast is valid if it is valid for at least one element of <literal>S</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>if <literal>S</literal> and <literal>T</literal> are generics, and if <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>S</mi><mn>0</mn></msup><mo>=</mo><msup><mi>T</mi><mn>0</mn></msup></math>,
-a cast is possible if type arguments are sub- or supertypes of each other: <footnote><simpara><literal>i</literal> iterates over all type args</simpara></footnote></simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>S</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Classifier</mtext></mstyle><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Classifier</mtext></mstyle><mo>∧</mo><msup><mi>S</mi><mn>0</mn></msup><mo>=</mo><msup><mi>T</mi><mn>0</mn></msup><mo>→</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="2.0em"/><mrow><mo>(</mo><mrow><mo>∀</mo><mi> </mi><mi>S</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><msub><mi>g</mi><mi>i</mi></msub><mo><</mo><mi>:</mi><mi>T</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><msub><mi>g</mi><mi>i</mi></msub><mo>)</mo></mrow><mo>∨</mo><mrow><mo>(</mo><mrow><mo>∀</mo><mi> </mi><mi>T</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><msub><mi>g</mi><mi>i</mi></msub><mo><</mo><mi>:</mi><mi>S</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><msub><mi>g</mi><mi>i</mi></msub><mo>)</mo></mrow></mrow></mrow></math></simpara>
-</listitem>
-<listitem>
-<simpara>If <literal>T</literal> is a union type, then the type cast is valid if it is valid for at least one element of <literal>T</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>If <literal>T</literal> is an intersection type, then the type cast is valid if it is valid for all elements of <literal>T</literal>.</simpara>
-</listitem>
-</orderedlist>
-<note>
-<simpara><literal>any</literal> is a supertype of all other types, thus it is always possible to cast a variable of type <literal>any</literal> to other (non-composed) types.</simpara>
-</note>
-</requirement>
-</section>
-<section xml:id="_type-check">
-<title>Type Check</title>
-<simpara>There are basically two ways of testing the type of a variable: <literal>typeof</literal> and <literal>instanceof</literal>.
-N4JS supports type comparison via the ECMAScript <literal>instanceof</literal> operator.
-The operator <literal>instanceof</literal> retains its standard ECMAScript behavior (e.g. checking whether a value is an instance of a constructor function), but has additional functionality when used with N4JS types.</simpara>
-<simpara>When used with an N4JS class, <literal>instanceof</literal> also supports checking against an interface. For N4JS enumeration values, it can be used to check whether the value is part of a specific enumeration.</simpara>
-<simpara><literal>typeof</literal> only returns a string with the name of the ECMAScript type, which is <literal>Object</literal> for all class instances.</simpara>
-<simpara>N4JS specific <literal>string</literal> types, that is <literal>pathSelector</literal> and <literal>i18nkey</literal> cannot be tested during runtime.
-These types, therefore, must not be used in <literal>instanceof</literal> expressions.
-The same is true for string-based enums and arrays which cannot be tested during runtime, thus string-based enum and array types are not permitted on the right-hand side of <literal>instancesof</literal> constructs.
-For all types for which the evaluation result of <literal>instanceof</literal> could be computed at compile time, the check is unnecessary and thus it is refused by the compiler.
-Using structural types on the right-hand side of <literal>instancesof</literal> constructs is also not permitted.</simpara>
-<simpara>In order to avoid errors at runtime, the <literal>instanceof</literal> operator defines appropriate constraints, see <xref linkend="_relational-expression"/> for details.</simpara>
-<example>
-<title>Type Check Example</title>
-<simpara>Given the following classes and variable:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface I{}
-class S{}
-class Sub extends S implements I{}
-
-var x = new Sub();</programlisting>
-</example>
-<simpara><literal>typeof x</literal> will simply return <literal>object</literal>. The following table shows the difference between plain JavaScript <literal>instanceof</literal> and N4JS’s <literal>instanceof</literal>:</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Check</entry>
-<entry align="center" valign="top">JavaScript</entry>
-<entry align="center" valign="top">N4JS</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><literal>x instanceof Sub</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>true</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>true</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>x instanceof S</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>true</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>true</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>x instanceof I</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>false</literal></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>true</literal></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</section>
-</section>
-<section xml:id="_reflection-meta-information" role="language-n4js">
-<title>Reflection meta-information</title>
-<simpara>All N4JS classes, interfaces and enumerations provide meta-information
-that is used by the runtime and standard library.
-All classifiers (including enums) provide meta-information by means of a static getter <literal>n4type</literal>.
-Since it is static getter, it is actually an instance getter of the
-constructor (or classifier) of a type, which is the only way to retrieve
-that information in case of interfaces. For enums, this can be retrieved
-from instances as well.</simpara>
-<simpara>This getter is of type <literal>N4Class</literal> which is a built-in type just like <literal>N4Object</literal>. It contains the following members:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>fqn</literal> </term>
-<listitem>
-<simpara>The <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mi>Q</mi><mi>N</mi></math> of the type.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>n4superType</literal> </term>
-<listitem>
-<simpara>The <literal>N4Class</literal> of the supertype, may be null if supertype is a not an <literal>N4Class</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>allImplementedInterfaces</literal> </term>
-<listitem>
-<simpara>List of The <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mi>Q</mi><mi>N</mi></math> of implemented interfaces (transitively
-but without interfaces implemented by supertype)</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>get isClass</literal> </term>
-<listitem>
-<simpara>True if the type is an N4Class.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>get isInterface</literal> </term>
-<listitem>
-<simpara>True if the type is an N4Interface.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<section xml:id="_reflection-for-classes">
-<title>Reflection for Classes</title>
-<simpara>The meta-information for classes is available by means of <literal>N4Object</literal>’s static
-getter <literal>n4type</literal>. Since it is static getter, it is actually an instance getter of the constructor of a type.</simpara>
-<simpara>In addition, the static method <literal>of</literal> in <literal>N4Type</literal> is available to retrieve the meta-information for a given instance or
-constructor. This also allows to retrieve meta-information directly for an instance of some class <literal>C</literal> without having
-the constructor of <literal>C</literal> available, for example because the constructor is not accessible.</simpara>
-<example>
-<title>Reflection with <literal>N4class</literal></title>
-<simpara>This example demonstrates how these reflective features are accessed:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {}
-class B extends A {}
-var b = new B();
-console.log(B.n4type.fqn);
-console.log(b.constructor.n4type.fqn);
-console.log(b.constructor.n4type.n4superType.fqn);
-console.log(N4Type.of(b));
-console.log(N4Type.of(B.n4type).fqn);</programlisting>
-<simpara>Assuming this code is defined in file <literal>A</literal>, this will output</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">A.B
-A.B
-A.A
-A.B
-N4BuiltInClasses.N4Class</programlisting>
-</example>
-<simpara>The built-in types <literal>N4Object</literal> and <literal>N4Class</literal> are also accessible.
-They are not defined in a module, thus their <link linkend="_acronyms">FQN</link> returns only their simple name.</simpara>
-<example>
-<title>Reflection with Built-In Types</title>
-<programlisting language="n4js" linenumbering="unnumbered">console.log('N4Object.n4class.fqn: ' + N4Object.n4class.fqn)
-console.log('N4Class.n4class.fqn: ' + N4Class.n4class.fqn)
-
-class A {}
-console.log('A.n4class.fqn: ' + A.n4class.fqn)
-console.log('A.n4class.n4superType.fqn: ' + A.n4class.n4superType.fqn)</programlisting>
-<simpara>Assuming this code is defined in file <literal>A</literal>, this will output</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">N4Object.n4class.fqn: N4Object
-N4Class.n4class.fqn: N4Class
-A.n4class.fqn: A.A
-A.n4class.n4superType.fqn: N4Object</programlisting>
-<simpara>Note that classes extending <literal>Object</literal> do not provide the static <literal>n4class</literal> getter, hat is</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class B extends Object {}
-console.log('B.n4class.fqn: ' + B.n4class.fqn)</programlisting>
-<simpara>would issue an error as cannot be resolved.</simpara>
-</example>
-<example>
-<title>N4Class.of</title>
-<simpara>The type has a method to retrieve the meta-information from instances (i.e. or enumeration literals using )
-without using the constructor.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C { }
-interface I {} class IImpl implements I {}
-enum E { L }
-
-var c: C = new C();
-var i: I = new IImpl();
-var e: E = E.L;
-
-console.log(C.n4type.fqn);
-console.log(N4Class.of(c).fqn);
-
-console.log(I.n4type.fqn);
-console.log(N4Class.of(i).fqn);
-
-console.log(E.n4type.fqn);
-console.log(N4EnumType.of(e).fqn);</programlisting>
-</example>
-</section>
-<section xml:id="_reflection-for-interfaces">
-<title>Reflection for Interfaces</title>
-<simpara>The meta-information of an interface <literal>X</literal> is available via getter <literal>n4class</literal> defined in the <literal>type{X}</literal>.
-This field is of type <literal>N4Class</literal> as well.
-Since an interface cannot have a super classs, the property <literal>n4superTypes</literal> will always be empty.
-Calling <literal>isInterface</literal> respectively on the returned <literal>N4Class</literal> instance will return true.</simpara>
-</section>
-<section xml:id="_reflection-for-enumerations">
-<title>Reflection for Enumerations</title>
-<programlisting language="n4js" linenumbering="unnumbered">var n: number; var b: boolean; var s: string;</programlisting>
-<simpara>The meta-information for enumerations is available by means of the getter <literal>n4class</literal>, either statically by using the enumeration type or (in terms of an instance getter) via a literal.
-Calling <literal>isEnum</literal> on the returned <literal>N4Class</literal> instance will return true.</simpara>
-</section>
-</section>
-<section xml:id="_conversion-of-primitive-types" role="language-n4js">
-<title>Conversion of primitive types</title>
-<simpara>Conversion between primitives is given as follows:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var n: number; var b: boolean; var s: string;</programlisting>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="4">
-<colspec colname="col_1" colwidth="11.1111*"/>
-<colspec colname="col_2" colwidth="11.1111*"/>
-<colspec colname="col_3" colwidth="44.4444*"/>
-<colspec colname="col_4" colwidth="33.3334*"/>
-<thead>
-<row>
-<entry align="center" valign="middle">From</entry>
-<entry align="center" valign="middle">To</entry>
-<entry align="left" valign="middle">Conversion</entry>
-<entry align="center" valign="top">Example</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="center" valign="middle"><simpara><literal>string</literal></simpara></entry>
-<entry align="center" valign="middle"><simpara><literal>number</literal></simpara></entry>
-<entry align="left" valign="middle"><simpara><literal>Number…​</literal></simpara></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">n = Number("42");//42</programlisting></entry>
-</row>
-<row>
-<entry align="center" valign="middle"><simpara><literal>string</literal></simpara></entry>
-<entry align="center" valign="middle"><simpara><literal>boolean</literal></simpara></entry>
-<entry align="left" valign="middle"><simpara><literal>N4Primitives.parseBoolean(…​)</literal></simpara></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered"> b=N4Primitives.parseBoolean("false");</programlisting></entry>
-</row>
-<row>
-<entry align="center" valign="middle"><simpara><literal>number</literal></simpara></entry>
-<entry align="center" valign="middle"><simpara><literal>boolean</literal></simpara></entry>
-<entry align="left" valign="middle"><simpara><literal>Boolean(…​)</literal></simpara></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">b=Boolean(17.5); //true</programlisting></entry>
-</row>
-<row>
-<entry align="center" valign="middle"><simpara><literal>number</literal></simpara></entry>
-<entry align="center" valign="middle"><simpara><literal>string</literal></simpara></entry>
-<entry align="left" valign="middle"><simpara><literal>Number.toString()</literal></simpara></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">s=42.toString(); //"42"</programlisting></entry>
-</row>
-<row>
-<entry align="center" valign="middle"><simpara><literal>boolean</literal></simpara></entry>
-<entry align="center" valign="middle"><simpara><literal>number</literal></simpara></entry>
-<entry align="left" valign="middle"><simpara><literal>N4Primitives.toNumber(…​)</literal></simpara></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered">n=N4Primitives.toNumber(true);</programlisting></entry>
-</row>
-<row>
-<entry align="center" valign="middle"><simpara><literal>boolean</literal></simpara></entry>
-<entry align="center" valign="middle"><simpara><literal>string</literal></simpara></entry>
-<entry align="left" valign="middle"><simpara><literal>Boolean.toString()</literal></simpara></entry>
-<entry align="left" valign="top"><programlisting language="n4js" linenumbering="unnumbered"> s=true.toString();//"true" }</programlisting></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Remarks:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>ECMAScript doesn’t define explicit conversion from string content.
-Implicit handling states all strings with <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>></mo><mn>0</mn><mo>=</mo><mo>=</mo><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi></math>. <literal>N4Primitives.parseBoolean(x)</literal> yields true for <literal>x.trim().toLowerCase().equals("true")</literal></simpara>
-</listitem>
-<listitem>
-<simpara>The call to <literal>Boolean(..)</literal> for the arguments <literal>0</literal>, <literal>-0</literal>, <literal>null</literal>, <literal>false</literal>, <literal>NaN</literal>, <literal>undefined</literal> and <literal>""</literal> evaluate to <literal>false</literal>.
-All other values evaluate to <literal>true</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>Number</literal> has several methods for converting a value to string [<link linkend="ECMA11a">ECMA11a(p.S15.7.4)</link>]: <literal>toExponential()</literal>, to <literal>Fixed()</literal>, <literal>toPrecision()</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>ECMAScript doesn’t define explicit conversion from boolean to number.
-Implicit handling states true <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>→</mo></math> 1 and false <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>→</mo></math> 0, which <literal>N4Primitives.toNumber()</literal> yields.</simpara>
-</listitem>
-</orderedlist>
-</section>
-</chapter>
-<chapter xml:id="_expressions">
-<title>Expressions</title>
-<simpara>For all expressions, we define the following pseudo properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>containingExpression</literal> </term>
-<listitem>
-<simpara>The parent expression, in which an expression is contained, may be null.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>containingStatement</literal> </term>
-<listitem>
-<simpara>The statement in which the expression is (indirectly) contained.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>containingFunctionOrAccessor</literal> </term>
-<listitem>
-<simpara>The function, method, getter or setter in which the expression is (indirectly) contained, may be null.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>containingClass</literal> </term>
-<listitem>
-<simpara>The class in which the expression is (indirectly) contained, may be null.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>probableThisTarget</literal> </term>
-<listitem>
-<simpara>The potential target of a this keyword binding, this is not necessarily the containing class or object literal.
-In case of instance methods of a class <literal>T</literal>, this usually is the classifier <literal>T</literal>; in case of static methods, it is the classifier type <literal>type{type}</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>container</literal> </term>
-<listitem>
-<simpara>The direct owner of the expression.
-z</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The expressions and statements are ordered, describing first the constructs available in the 5th edition of ECMA-262, referred to as [<link linkend="ECMA11a">ECMA11a</link>] in the following.
-It is worth noting that the grammar snippets already use newer constructs in some cases.</simpara>
-<section xml:id="_ecmascript-5-expressions" role="language-n4js">
-<title>ECMAScript 5 Expressions</title>
-<simpara>N4JS supports the same expressions as ECMAScript.
-The semantics are described in [<link linkend="ECMA11a">ECMA11a(p.S11)</link>].
-In N4JS, some expressions are extended for supporting the declaration of types, annotations, or parameterized usages.
-These extensions and type-related aspects as well as specific N4JS constraints are described in this section.</simpara>
-<simpara>Some operators come in different ’flavors’, that is as binary operator, unary pre- or postfix operators, or assignment operators.
-For these operators, type constraints are only defined for the binary operator version and the other variants are deduced to that binary version.
-E.g., <literal>++</literal> and <literal>+=</literal> are deduced to <literal>+</literal> (and simple assignment).</simpara>
-<section xml:id="_the-this-literal">
-<title>The this Literal</title>
-<simpara>This section describes the <literal>this</literal> literal and the semantics of the <literal>@This</literal> annotation, the type <literal>this</literal> is described in <xref linkend="_this-type"/>.</simpara>
-<bridgehead xml:id="_semantics-9" renderas="sect4">Semantics</bridgehead>
-<simpara>Semantics are similar to the original ECMAScript this keyword, see [<link linkend="ECMA11a">ECMA11a(p.11.1.1, p.p.63)</link>])
-Also see [<link linkend="West06a">West06a</link>] and <link xl:href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this">MozillaJSRef</link></simpara>
-<simpara>Regarding the location where <literal>this</literal> may be used, the following restrictions apply:</simpara>
-<requirement xml:id="IDE-173">
-<title>Valid location for this literal</title>
-<simpara>
-<anchor xml:id="Req-IDE-173" xreflabel="[Req-IDE-173]"/>
-<emphasis role="strong">Requirement: IDE-173:</emphasis>
-<link linkend="Req-IDE-173">Valid location for this literal</link> (ver. 1)</simpara>
- <simpara>
-
-The literal may not be used in</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>the initializer expression of static data fields in classes.</simpara>
-</listitem>
-<listitem>
-<simpara>the initializer expression of data fields in interfaces (applies to both static and non-static).</simpara>
-</listitem>
-<listitem>
-<simpara>static methods of interfaces and static field accessors of interfaces.</simpara>
-</listitem>
-</orderedlist>
-<simpara>See also <xref linkend="Req-IDE-69"/>.</simpara>
-</requirement>
-<simpara>Note: <xref linkend="Req-IDE-173"/> also applies for this literals inside arrow expressions in initializers.</simpara>
-<simpara>The use of <literal>this</literal> is illustrated with some examples as it can often be confusing.
-Type inference heuristics and explanations are provided in the next section.</simpara>
-<example>
-<title>This in Unrestricted Mode</title>
-<simpara>In unrestricted mode, <literal>this</literal> is bound to the receiver.
-If there is no receiver it is bound to the global object, however, we often do not know exactly what the global object would be.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var name = "global a"; // assume the top level is similar to the global object
-this.name; // <-- "global a"
-function f() {
- return this.name; // <-- depends on call, usually "global a"
-}
-var ol1 = {
- name: "John",
- greeting: "Hello " + this.name, // "Hello global a" -- we do not greet John!
-}
-var ol2 = {
- name: "John",
- f: function() {
- this.name; // usually "John", as we assume f is called like ol2.f()
- var g = function() {
- return this.name; // "global a"
- }
- return g(); // no receiver, this in nested function g will be global scope
- }
-}</programlisting>
-</example>
-<example>
-<title>This in strict mode</title>
-<simpara>In strict mode, <literal>this</literal> is bound to the receiver.
-If there is no receiver, it is bound to <literal>undefined</literal>.
-Thus, we will probably get a lot of errors:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">"use strict"
-var name = "global a"; // assume the top level is similar to the global object
-this.name; // <-- error, this is undefined, there is no receiver
-function f() {
- return this.name; // <-- depends on call, usually this produces an error as this is undefined
-}
-var ol1 = {
- name: "John",
- greeting: "Hello " + this.name, // will produce an error, as this is undefined
-}
-var ol2 = {
- name: "John",
- f: function() {
- this.name; // usually "John", as we assume f is called like ol2.f()
- var g = function() {
- this.name; // an error, see call below:
- }
- return g(); // no receiver, this in nested function g is undefined
- }
-}</programlisting>
-</example>
-<example>
-<title>This in N4JS mode</title>
-<simpara>As in strict mode, <literal>this</literal> is bound to the receiver and if there is no receiver, it is bound to <literal>undefined</literal>. So the example above is also true for N4JS mode.
-Classes behave slightly differently:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- name = "John";
- greeting = "Hello " + this.name; // works, in N4JS classes, greeting is "Hello John"
-
- f() {
- return this.name; // this usually is instance object, similar to object literals.
- }
-
- g() {
- var h = function() {
- return this.name; // as in object literals: no receiver, no this.
- }
- return h();
- }
-}</programlisting>
-</example>
-<note>
-<simpara>In N4JS classes, <literal>this</literal> is always bound to the instance when used in field initialization.</simpara>
-</note>
-<bridgehead xml:id="_type-inference-2" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type is inferred from the <literal>this</literal> type is bound to. The inference,
-therefore, has to consider the original semantics as described in [<link linkend="ECMA11a">ECMA11a(p.10.4., p.10.4.3, p.p.58)</link>].
-In ECMAScript the type of this is unfortunately determined by the function call and not by the function definition:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>By default, <literal>this</literal> is bound to the global object [<link linkend="ECMA11a">ECMA11a(p.10.4.1.1)</link>].
-Unfortunately it is often unknown what the global object will be at run time (e.g., node.js differs from browsers).</simpara>
-</listitem>
-<listitem>
-<simpara>If a function is called without a receiver, <literal>this</literal> is bound to</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the global object or</simpara>
-</listitem>
-<listitem>
-<simpara>to <literal>undefined</literal> in strict mode.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>If a function is called with a receiver,<literal>this</literal> is bound to the receiver object.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Actually, <literal>this</literal> is bound to the newly created object if a function is called with the <literal>new</literal> operator.
-If a function is known to be invoked with an explicit <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>h</mi><mi>i</mi><mi>s</mi><mi>A</mi><mi>r</mi><mi>g</mi></math> (<literal>apply()</literal> etc.), the <literal>@This</literal> annotation can be used to explicitly set the this type.
-This annotation has precedence over otherwise inferred bindings.</simpara>
-<requirement xml:id="IDE-90">
-<title>Type Inference Heuristic for This-Keyword</title>
-<simpara>
-<anchor xml:id="Req-IDE-90" xreflabel="[Req-IDE-90]"/>
-<emphasis role="strong">Requirement: IDE-90:</emphasis>
-<link linkend="Req-IDE-90">Type Inference Heuristic for This-Keyword</link> (ver. 1)</simpara>
- <simpara>
-
-In general, the actual this target can not be inferred from the context of the this keyword.
-A heuristic is defined, however, to compute the probable this type:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><anchor xml:id="this-keyword-constraint-1" xreflabel="[this-keyword-constraint-1]"/> If the this keyword is used in some function annotated with an annotation <literal>@This</literal>, the type specified in the annotation is used.
-The inferred type is always nominal.</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>"this"</mtext></mstyle><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>O</mi><mi>r</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>o</mi><mi>r</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mfrac><mrow><mi>f</mi><mo>.</mo><mi>h</mi><mi>a</mi><mi>s</mi><mi>A</mi><mi>n</mi><mi>n</mi><mi>o</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close=")" open="("><mstyle mathvariant="monospace"><mtext>"@This"</mtext></mstyle></mfenced><mspace width="3.0mm"/><mi>T</mi><mo>=</mo><mi>f</mi><mo>.</mo><mi>a</mi><mi>n</mi><mi>n</mi><mi>o</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mstyle mathvariant="monospace"><mtext>["@This"]</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>"this"</mtext></mstyle><mi>:</mi><mo>≁</mo><mi>T</mi></mrow></mfrac></math></simpara>
-</listitem>
-<listitem>
-<simpara><anchor xml:id="this-keyword-constraint-2" xreflabel="[this-keyword-constraint-2]"/> If the this keyword is used in some <emphasis>instance</emphasis> method of a classifier or in an <emphasis>instance</emphasis> field initializer,<literal>this</literal> is bound to the <literal>T</literal> itself.
-If the this keyword is used in some <emphasis>static</emphasis> method of a classifier <literal>T</literal> or in a <emphasis>static</emphasis> field initializer, the prototype type (or constructor) of the classifier is used, that is <literal>type[T]</literal>.
-In both cases, the target is determined by using the expressions’s pseudo property <literal>probableThisTarget</literal>.
-If the this keyword is used in a function expression assigned to an property of an object literal, the type of the object literal is used.
-Note that usually this is the <literal>this</literal> type in instance methods, and the <literal>this</literal> type in static methods.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>T</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>"this"</mtext></mstyle><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>b</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi><mi>T</mi><mi>h</mi><mi>i</mi><mi>s</mi><mi>T</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mspace width="3.0mm"/><mi>T</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>"this"</mtext></mstyle><mi>:</mi><mo>≁</mo><mi>T</mi></mrow></mfrac><mtext>
-</mtext></math>
-</listitem>
-<listitem>
-<simpara>In all other cases: Non-strict mode:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>m</mi><mi>o</mi><mi>d</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>unrestricted</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>"this"</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>global</mtext></mstyle></mrow></mfrac><mtext>
-</mtext></math>
-</listitem>
-</orderedlist>
-<simpara>Strict mode and N4JS mode:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>m</mi><mi>o</mi><mi>d</mi><mi>e</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>unrestricted</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>"this"</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>global</mtext></mstyle><mstyle mathvariant="monospace"><mtext>undefined</mtext></mstyle></mrow></mfrac><mtext>
-</mtext></math>
-</requirement>
-<simpara>If the actual this type is defined as a structural type, the structural type information is moved to the this type itself.
-This is transparent to the user in general but maybe visible in case of error messages.
-That is to say that the actual this type is always a nominal type.
-This is indicated by the nominal modifier <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>≁</mo></math> (cf. <xref linkend="Req-IDE-90"/> constraints <link linkend="this-keyword-constraint-1">1</link> and <link linkend="this-keyword-constraint-2">2</link>.).</simpara>
-<requirement xml:id="IDE-91">
-<title>Valid Target and Argument for @This Annotation</title>
-<simpara>
-<anchor xml:id="Req-IDE-91" xreflabel="[Req-IDE-91]"/>
-<emphasis role="strong">Requirement: IDE-91:</emphasis>
-<link linkend="Req-IDE-91">Valid Target and Argument for @This Annotation</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The <literal>@This</literal> annotation is only allowed on declared functions, function expressions (including arrow functions), methods, and field accessors, i.e. getters and setters, except static members of interfaces.</simpara>
-</listitem>
-<listitem>
-<simpara>The type declared by way of <literal>@This(..)</literal> an annotation of a method or field accessor must be a subtype of the member’s containing classifier.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-92">
-<title>Single @This Annotation</title>
-<simpara>
-<anchor xml:id="Req-IDE-92" xreflabel="[Req-IDE-92]"/>
-<emphasis role="strong">Requirement: IDE-92:</emphasis>
-<link linkend="Req-IDE-92">Single @This Annotation</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>It is not allowed to use more then one <literal>@This(..)</literal> annotation on an element.</simpara>
-</requirement>
-<example>
-<title>Effect of Nominal This Type</title>
-<simpara>Given the following declaration</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">@This(~Object with {a: string;}) f() {}</programlisting>
-<simpara>Since the this type is always nominal, <literal>~ Object</literal> becomes <literal>Object</literal>.
-In case of method call, however, the returned value becomes structural again.
-In case of error messages the type of the return type is then</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">~this[Object] with {a: string;}</programlisting>
-<simpara>For the sake of simplicity, additional structural members are usually
-omitted in error messages, leading to</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">~this[Object]</programlisting>
-<simpara>instead of</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">this[~Object]</programlisting>
-</example>
-<example>
-<title>This and Function Declaration</title>
-<simpara>This example demonstrates the usage of functions annotated with <literal>@This</literal>.
-By using the argument <literal>union{A,B}</literal> it is possible to have two completely unrelated classes as the receiver type of the function <literal>logger</literal>.
-To pass an actual object the <literal>apply()</literal> method of the function is used.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- log: string() { return "A was logged"; }
-}
-
-class B {
- log: string() { return "B was logged"; }
-}
-
-@This(union{A,B})
-function logger() { console.log("~ "+this.log()+" ~"); }
-
-
-var a: A = new A();
-logger.apply(a,[]); // prints "~ A was logged ~"
-logger.apply( new B(),[]) // prints "~ B was logged ~"</programlisting>
-</example>
-<example>
-<title>This and Function Expressions</title>
-<simpara>In this example a function is created via a function expression.
-The function is then assigned to member field of class B.
-Via annotating the expression with <literal>@This(B)</literal>, access to the receiver of type B is enabled.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class B {
- log(): string { return "B was logged"; } // method
- logMe : {@This(B) function():void}; // reference to a function
-}
-
-var b: B = new B();
-b.logMe = @This(B) function() { console.log("*>"+this.log()+"<*"); }
-b.logMe(); // prints "*>B was logged<*"</programlisting>
-
-<simpara>Note that if a function is called as a constructor function with new, the
-type of <literal>this</literal> can be declared via annotation <literal>@This(..)</literal>, as shown in the following
-snippet:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">@This(
- ~Object with {
- w: number; h: number;
- area: {function():number};
- })
-function Box(w: number w, h: number) {
- this.w = w;
- this.h = h;
- this.area = @This(
- ~Object with {
- w: number; h: number;
- area: {function():number};
- }) function() { return this.w * this.h }
-}
-var bError = Box(1,2)
-var bOK = new Box(1,2)</programlisting>
-</example>
-<simpara>Inside the constructor function <literal>Box</literal>, <literal>this</literal> is bound to the structural type definition due to the annotation.</simpara>
-<simpara>Inside the nested function <literal>area</literal>, <literal>this</literal> is bound to the receiver object (if the function is called like <literal>bOk.area()</literal>).
-Again, this depends on the way the nested function is called, which can usually not be determined at the declaration location.
-The nested function must then be annotated accordingly.</simpara>
-<simpara>When calling this function, the type of this is checked against the declared this type, which would cause an error in the first case.</simpara>
-<simpara>The use of the <literal>@This</literal> annotation is not allowed on methods.</simpara>
-<tip>
-<simpara>Using constructor functions is not recommended and an error or warning will be created.
-This is only useful for adapting third-party library code.
-Even in the latter case, it would probably make more sense to declare a (library) <emphasis role="strong">class</emphasis> Rectangle rather then defining the constructor function.</simpara>
-</tip>
-</section>
-<section xml:id="_identifier">
-<title>Identifier</title>
-<bridgehead xml:id="_syntax-10" renderas="sect4">Syntax</bridgehead>
-<simpara>Identifiers as expressions are identifier references.
-They are defined as follows:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">IdentifierRef <Yield>:
- id=[types::IdentifiableElement|BindingIdentifier<Yield>]
-;
-
-BindingIdentifier <Yield>:
- IDENTIFIER
- | <!Yield> 'yield'
- | N4Keyword
-;</programlisting>
-<bridgehead xml:id="_semantics-10" renderas="sect4">Semantics</bridgehead>
-<simpara>The type of an identifier <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> is resolved depending on its binding and scope respectively (cf. [<link linkend="ECMA11a">ECMA11a(p.10.2.2.1GetIdentifierReference, p.p.56)</link>].
-The following scopes (aka <emphasis>Lexical Environments</emphasis>) are defined:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>function local; local variables, parameters</simpara>
-</listitem>
-<listitem>
-<simpara>zero or more function closure in case of nested functions</simpara>
-</listitem>
-<listitem>
-<simpara>module</simpara>
-</listitem>
-<listitem>
-<simpara>global</simpara>
-</listitem>
-</itemizedlist>
-<simpara>These scope are nested as illustrated in <xref linkend="fig:scopes"/>.</simpara>
-<simpara>Note that classes definitions and object literal do not define a scope: members of a class or properties of an object literal are to be accessed via <literal>this</literal>.
-Identifier references always reference declared elements, that is to say either variable, function, or class declarations.
-Properties of object literals or members of a class are referenced via <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mo>-</mo><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi></math> (see <xref linkend="_property-accessors"/>).</simpara>
-<figure xml:id="fig:scopes">
-<title>Scopes</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/08_expressions/fig/scopes.svg" width="40%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>scopes</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>An identifier may be bound to a variable (global or local variable, parameter, variable defined in a function’s closure), or to a property of an object.
-The latter case is known as property access as further described in <xref linkend="_property-accessors"/>.</simpara>
-<requirement xml:id="IDE-93">
-<title>Read Access to Identifier</title>
-<simpara>
-<anchor xml:id="Req-IDE-93" xreflabel="[Req-IDE-93]"/>
-<emphasis role="strong">Requirement: IDE-93:</emphasis>
-<link linkend="Req-IDE-93">Read Access to Identifier</link> (ver. 1)</simpara>
- <simpara>
-
-If an identifier <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> is accessed, the bound declared element <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math> must be readable if it is not used on the left-hand side of an assignment expression.</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mi>i</mi><mi>D</mi></mfenced></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="2.0em"/><mo>∧</mo><mo>∄</mo><mi> </mi><mstyle mathvariant="monospace"><mtext>AssignmentExpression</mtext></mstyle><mi> </mi><mi>a</mi><mi>e</mi><mo>∈</mo><mi>i</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><msup><mi>r</mi><mo>*</mo></msup><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="3.0em"/><mi>a</mi><mi>e</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>=</mo><mi>i</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mspace width="4.0em"/><mo>∨</mo><mfenced close=")" open="("><mrow><mi>μ</mi><mfenced close=")" open="("><mrow><mi>a</mi><mi>e</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>PropertyAccessExpression</mtext></mstyle><mo>∧</mo><mi>a</mi><mi>e</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mo>=</mo><mi>i</mi></mrow></mfenced><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>⇒</mo><mi>D</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>a</mi><mi>d</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math></simpara>
-</requirement>
-<bridgehead xml:id="_type-inference-3" renderas="sect4">Type Inference</bridgehead>
-<simpara>An identifier reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> is bound to an identifiable element <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mo>.</mo><mi>i</mi><mi>d</mi></math>, which is expressed with the function <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mi>i</mi><mrow><mi>i</mi><mo>.</mo><mi>i</mi><mi>d</mi></mrow></mfenced></math>.
-The type of the reference is then inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>i</mi><mi>d</mi><mi>r</mi><mi>e</mi><mi>f</mi><mo>.</mo><mi>i</mi><mi>d</mi><mi>:</mi><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>IdentifierRef</mtext></mstyle><mi> </mi><mi>i</mi><mi>d</mi><mi>r</mi><mi>e</mi><mi>f</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-</section>
-<section xml:id="_literals">
-<title>Literals</title>
-<simpara>cf. [<link linkend="ECMA11a">ECMA11a(p.S11.1.3p.63, p.S7.8p.19ff)</link>].</simpara>
-<bridgehead xml:id="_type-inference-4" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type of a literal can directly be derived from the grammar.
-The following axioms are defined for literals:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="13.0em"/><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>NullLiteral</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="13.0em"/><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>BooleanLiteral</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>boolean</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="13.0em"/><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>NumericLiteral</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>int</mtext></mstyle><mi>o</mi><mi>r</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="13.0em"/><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>StringLiteral</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="13.0em"/><mfrac><mrow/><mrow><mstyle mathvariant="monospace"><mtext>RegularExpressionLiteral</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>RegExpr</mtext></mstyle></mrow></mfrac></math></simpara>
-<simpara>Note that there are no literals specific for <literal>pathSelector</literal> or <literal>i18nkey</literal>.</simpara>
-<section xml:id="_integer-literals">
-<title>Integer Literals</title>
-<simpara>Numeric literals representing integers in the range of JavaScript’s int32 are inferred to the built-in primitive type <literal>int</literal> instead of <literal>number</literal>.
-The following rules apply:</simpara>
-<requirement xml:id="IDE-94">
-<title>Numeric literals</title>
-<simpara>
-<anchor xml:id="Req-IDE-94" xreflabel="[Req-IDE-94]"/>
-<emphasis role="strong">Requirement: IDE-94:</emphasis>
-<link linkend="Req-IDE-94">Numeric literals</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Numeric literals with a fraction or using scientific notation, e.g. <literal>2.0</literal> and <literal>2e0</literal>, respectively, are always inferred to <literal>number</literal>, even if they represent integers in the range of int32.</simpara>
-</listitem>
-<listitem>
-<simpara>Numeric literals that represent integers in the range of JavaScript’s int32, i.e. from <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mn>-2</mn><mn>31</mn></msup></math> to <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mn>2</mn><mn>31</mn></msup><mo>-</mo><mn>1</mn></math>, are inferred to <literal>int</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Hexadecimal and octal literals are always interpreted as positive numbers, so all values above <literal>0x7fffffff</literal> and <literal>017777777777</literal> lie outside the range of int32 and will thus
-be inferred to <literal>number</literal>; this is an important difference to Java. See below for further elaboration.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>There are differences to numeric literals in Java:</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="5">
-<colspec colname="col_1" colwidth="25*"/>
-<colspec colname="col_2" colwidth="25*"/>
-<colspec colname="col_3" colwidth="12.5*"/>
-<colspec colname="col_4" colwidth="25*"/>
-<colspec colname="col_5" colwidth="12.5*"/>
-<thead>
-<row>
-<entry align="left" valign="top"></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3">Java</entry>
-<entry align="center" valign="top" namest="col_3" nameend="col_4">JavaScript N4JS</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Literal</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Value</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Type</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Value</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Type</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>2147483648</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>-2147483648</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>-2147483648</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>2147483647</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>2147483647</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>2147483647</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>0x7fffffff</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>2147483647</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>2147483647</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>0x80000000</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>-2147483648</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>+2147483648</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>number</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>0xffffffff</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>-1</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>4294967295</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>number</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>0x100000000</literal></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3"><simpara><emphasis role="strong">n/a</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>4294967296</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>number</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>017777777777</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>2147483647</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>2147483647</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>020000000000</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>-2147483648</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>+2147483648</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>number</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>037777777777</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>-1</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>4294967295</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>number</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>040000000000</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>0</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>int</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>4294967296</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>number</literal></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>0100000000000</literal></simpara></entry>
-<entry align="center" valign="top" namest="col_2" nameend="col_3"><simpara><emphasis role="strong">n/a</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis>8589934592</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>number</literal></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>The literals <literal>0x100000000</literal> and <literal>0100000000000</literal> produce a syntax error in Java.</simpara>
-<simpara>Until IDE-1881 is complete, all built-in operations always return a <literal>number</literal> even if all operands are of type <literal>int</literal>.
-For the time being, we therefore interpret <literal>-1</literal> as a negative integer literal (inferred to <literal>int</literal>), but <literal>-(1)</literal> as the negation of a positive integer literal (inferred to <literal>number</literal>).</simpara>
-</requirement>
-</section>
-</section>
-<section xml:id="_array-literal">
-<title>Array Literal</title>
-<bridgehead xml:id="_syntax-11" renderas="sect4">Syntax</bridgehead>
-<simpara>cf [<link linkend="ECMA11a">ECMA11a(p.S11.1.4, p.p.63)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ArrayLiteral <Yield> returns ArrayLiteral:
- {ArrayLiteral} '['
- elements+=ArrayPadding* (
- elements+=ArrayElement<Yield>
- (',' elements+=ArrayPadding* elements+=ArrayElement<Yield>)*
- (trailingComma?=',' elements+=ArrayPadding*)?
- )?
- ']'
-;
-
-/**
- * This array element is used to pad the remaining elements, e.g. to get the
- * length and index right
- */
-ArrayPadding returns ArrayElement: {ArrayPadding} ',';
-
-ArrayElement <Yield> returns ArrayElement: {ArrayElement} spread?='...'? expression=AssignmentExpression<In=true,Yield>;</programlisting>
-<bridgehead xml:id="_type-inference-5" renderas="sect4">Type Inference</bridgehead>
-<simpara>In general, an array literal is inferred as <literal>Array<T></literal> (similar to the type of <literal>new Array()</literal>).
-The interesting question is the binding of the type variable <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>.</simpara>
-<simpara>The type of an array padding <emphasis>p</emphasis> is inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>p</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>undefined</mtext></mstyle></mrow></mfrac><mtext>
-</mtext></math>
-<simpara>The element type of an array literal is simply inferred as the (simplified) union of the type elements of the array.
-Thus, the type of an array literal <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi></math> is inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>a</mi><mo>.</mo><mover accent="true"><mrow><mi>e</mi><mi>l</mi><mi>e</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi></mrow><mo>¯</mo></mover><mi>:</mi><mover accent="true"><msub><mi>T</mi><mi>e</mi></msub><mo>¯</mo></mover><mi>T</mi><mo>=</mo><mo>⋃</mo><mover accent="true"><msub><mi>T</mi><mi>e</mi></msub><mo>¯</mo></mover></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mfenced close=")" open="("><mi>a</mi></mfenced><mi>:</mi><mi>A</mi><mi>r</mi><mi>r</mi><mi>a</mi><mi>y</mi><mo><</mo><mi>T</mi><mo>></mo></mrow></mfrac></math>
-<simpara>In other languages not supporting union types, the element type is often inferred as the join (<link linkend="_acronyms">LCST</link>) of the element types.
-Using a union type here preserves more information (as the actual types are still known).
-For many use cases the behavior is similar though, as the members of a union type are the members of the join of the elements of the union.</simpara>
-<simpara>Note that <literal>typeof [1,2,3]</literal> does not return <literal>Array<number></literal> (as ECMAScript is not aware of the generic array type), but <literal>Object</literal>.</simpara>
-<example>
-<title>Array Type Inference</title>
-<simpara>The type for all variables declared in this example is inferred to <literal>Array<string></literal>:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var names1 = ["Walter", "Werner"];
-var names2 = new Array("Wim", "Wendelin");
-var names3 = new Array<string>(3); // length is 3
-var names4: Array<string>;</programlisting>
-<simpara>Empty array literals are inferred to <literal>any</literal>, by default.
-We are not using <literal>Array<?></literal> here because then a typical JavaScript pattern would no longer be supported:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var a = [];
-a.push('hello'); <co xml:id="CO4-1"/></programlisting>
-<calloutlist>
-<callout arearefs="CO4-1">
-<para>This would fail if <literal>a</literal> and thus <literal>[]</literal> were inferred to <literal>Array<?></literal></para>
-</callout>
-</calloutlist>
-</example>
-<important>
-<simpara>An important exception; if a type expectation exists for the empty array literal and the expected type is <literal>Array<T></literal>, this will be used as the type of the array literal.</simpara>
-</important>
-<requirement xml:id="IDE-95">
-<title>Empty array literal</title>
-<simpara>
-<anchor xml:id="Req-IDE-95" xreflabel="[Req-IDE-95]"/>
-<emphasis role="strong">Requirement: IDE-95:</emphasis>
-<link linkend="Req-IDE-95">Empty array literal</link> (ver. 1)</simpara>
- <simpara>
-
-An empty array literal will be inferred as follows:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If there is a type expectation for the empty array literal and the expected type is <literal>Array<T></literal>, for any type <literal>T</literal>, then the type of the empty array literal will be inferred to <literal>Array<T></literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Otherwise, the type of the empty array literal will be inferred to <literal>Array<any></literal>.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-</section>
-<section xml:id="_object-literal">
-<title>Object Literal</title>
-<simpara>In addition to ordinary Javascript object literals, N4JS supports the spread operator within object literals as introduced in [<link linkend="ECMA18a">ECMA18a</link>].</simpara>
-<bridgehead xml:id="object-literal-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S11.1.5, p.p.65ff)</link>]
-The syntax of an object literal is given by:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ObjectLiteral <Yield>: {ObjectLiteral}
- '{'
- ( propertyAssignments+=PropertyAssignment<Yield>
- (',' propertyAssignments+=PropertyAssignment<Yield>)* ','?
- )?
- '}'
-;
-
-PropertyAssignment <Yield>:
- PropertyNameValuePair<Yield>
- | PropertyGetterDeclaration<Yield>
- | PropertySetterDeclaration<Yield>
- | PropertyMethodDeclaration<Yield>
- | PropertyNameValuePairSingleName<Yield>
- | PropertySpread<Yield>
-;
-
-
-PropertyMethodDeclaration <Yield>:
- => ({PropertyMethodDeclaration}
- annotations+=Annotation*
- TypeVariables? returnTypeRef=TypeRef?
- (
- generator?='*' LiteralOrComputedPropertyName<Yield> ->MethodParamsAndBody<Generator=true>
- | LiteralOrComputedPropertyName<Yield> ->MethodParamsAndBody <Generator=false>
- )
- )
- ';'?
-;
-
-PropertyNameValuePair <Yield>:
- => (
- {PropertyNameValuePair}
- annotations+=Annotation*
- declaredTypeRef=TypeRef? LiteralOrComputedPropertyName<Yield> ':'
- )
- expression=AssignmentExpression<In=true,Yield>
-;
-
-/*
- * Support for single name syntax in ObjectLiteral (but disallowed in actual object literals by ASTStructureValidator
- * except in assignment destructuring patterns)
- */
-PropertyNameValuePairSingleName <Yield>:
- declaredTypeRef=TypeRef?
- identifierRef=IdentifierRef<Yield>
- ('=' expression=AssignmentExpression<In=true,Yield>)?
-;
-
-PropertyGetterDeclaration <Yield>:
- =>(
- {PropertyGetterDeclaration}
- annotations+=Annotation*
- GetterHeader<Yield>
- )
- body=Block<Yield=false>
-;
-
-PropertySetterDeclaration <Yield>:
- =>(
- {PropertySetterDeclaration}
- annotations+=Annotation*
- 'set'
- ->LiteralOrComputedPropertyName <Yield>
- )
- '(' fpar=FormalParameter<Yield> ')' body=Block<Yield=false>
-;
-
-PropertySpread <Yield>:
- '...' expression=AssignmentExpression<In=true,Yield>
-;</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">import Address from "my/Address";
-var simple = {name: "Walter", age: 72, address: new Address()};</programlisting>
-<section xml:id="_properties-6">
-<title>Properties</title>
-<simpara>PropertyAssignments have common properties of PropertyNameValuePair, PropertyGetterDeclaration, and PropertySetterDeclaration:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>annotations</literal> </term>
-<listitem>
-<simpara>The annotations of the property assignment.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>name</literal> </term>
-<listitem>
-<simpara>The name of the property. This may be an identifier, a string or a numeric literal.
-When comparing names, we implicitly assume the name to be converted to an identifier, even if this identifier is not a valid ECMAScript identifier.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>declaredType</literal> </term>
-<listitem>
-<simpara>The declared type of the property which may be null.
-This property is a pseudo property for PropertySetterDeclaration, in this case it is derived from the declared type of the setter’s formal parameter.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Additionally, we introduce the following pseudo properties to simplify constraints:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>isAccessor</literal> </term>
-<listitem>
-<simpara>The read-only boolean property. This is true if the property assignment is a setter or getter declaration.
-This is comparable to ECMAScript’s spec function <literal>IsAccessoprDescriptor</literal>.
-For a given property assignment <emphasis>p</emphasis> this is semantically equivalent to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>p</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>PropertyGetterDeclaration</mtext></mstyle><mo>∨</mo><mi>μ</mi><mfenced close=")" open="("><mi>p</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>PropertySetterDeclaration</mtext></mstyle></math>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>isData</literal> </term>
-<listitem>
-<simpara>The read-only boolean property.
-This is true if the property assignment is a name value pair.
-For a given property assignment <emphasis>p</emphasis> this is semantically equivalent to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>p</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>PropertyNameValuePair</mtext></mstyle></math>.
-It is comparable to ECMAScript’s spec function <literal>isDataDescriptor</literal>.
-The equation <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mi>s</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>o</mi><mi>r</mi><mo>=</mo><mo>¬</mo><mi>i</mi><mi>s</mi><mi>D</mi><mi>a</mi><mi>t</mi><mi>a</mi></math> is always true.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="properties-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-96">
-<title>Object literal</title>
-<simpara>
-<anchor xml:id="Req-IDE-96" xreflabel="[Req-IDE-96]"/>
-<emphasis role="strong">Requirement: IDE-96:</emphasis>
-<link linkend="Req-IDE-96">Object literal</link> (ver. 1)</simpara>
- <simpara>
-
-For a given object literal <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>l</mi></math> the following constraints must hold (cf. [<link linkend="ECMA11a">ECMA11a(p.p.66)</link>]:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>the name of each property is given as an identifier, a string literal, a numeric literal, or as a computed property name with a compile-time expression (see <xref linkend="compile-time-expressions"/>). In particular, string literals, e.g. <literal>['myProp']</literal>, built-in symbols, e.g. <literal>[Symbol.iterator]</literal>, and literals of <literal>@StringBased</literal> enums are all valid computed property names.</simpara>
-</listitem>
-<listitem>
-<simpara>Object literal may not have two PropertyNameValuePairs with the same name in strict mode (cf. 4.a [<link linkend="ECMA11a">ECMA11a(p.p.66)</link>]):</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>o</mi><mi>d</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>strict</mtext></mstyle><mo>→</mo><mspace width="3.0mm"/><mo>∀</mo><mi>p</mi><mi>a</mi><mo>∈</mo><mi>o</mi><mi>l</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mo>,</mo><mi>p</mi><mi>a</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>D</mi><mi>a</mi><mi>t</mi><mi>a</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∄</mo><mi>p</mi><msup><mi>a</mi><mi>'</mi></msup><mo>∈</mo><mi>o</mi><mi>l</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>p</mi><msup><mi>a</mi><mi>'</mi></msup><mo>.</mo><mi>i</mi><mi>s</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>o</mi><mi>r</mi><mo>∧</mo><mi>p</mi><msup><mi>a</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>p</mi><mi>a</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Object literal may not have PropertyNameValuePair and <literal>PropertyGetterDeclaration</literal>/<literal>PropertySetterDeclaration</literal> with the same name (cf. 4.b/c [<link linkend="ECMA11a">ECMA11a(p.p.66)</link>]):</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mspace width="3.0mm"/><mi>p</mi><mi>a</mi><mo>∈</mo><mi>o</mi><mi>l</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mo>,</mo><mi>p</mi><mi>a</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>D</mi><mi>a</mi><mi>t</mi><mi>a</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∄</mo><mspace width="3.0mm"/><mi>p</mi><mi>g</mi><mi>s</mi><mi>d</mi><mo>∈</mo><mi>o</mi><mi>l</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mrow><mi>p</mi><mi>g</mi><mi>s</mi><mi>d</mi></mrow></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>PropertyNameValuePair</mtext></mstyle><mo>∧</mo><mi>p</mi><mi>g</mi><mi>s</mi><mi>d</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>p</mi><mi>a</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Object literal may not have multiple <literal>PropertyGetterDeclaration</literal> or <literal>PropertySetterDeclaration</literal> with the same name (cf. 4.d [<link linkend="ECMA11a">ECMA11a(p.p.66)</link>]):</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mspace width="3.0mm"/><mi>p</mi><mi>g</mi><mo>∈</mo><mi>o</mi><mi>l</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mo>,</mo><mi>p</mi><mi>g</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>o</mi><mi>r</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∄</mo><mspace width="3.0mm"/><mi>p</mi><msup><mi>g</mi><mi>'</mi></msup><mo>∈</mo><mi>o</mi><mi>l</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mfenced close="}" open="{"><mrow><mi>p</mi><mi>g</mi></mrow></mfenced><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mrow><mi>p</mi><msup><mi>g</mi><mi>'</mi></msup></mrow></mfenced><mo>=</mo><mi>μ</mi><mfenced close=")" open="("><mrow><mi>p</mi><mi>g</mi></mrow></mfenced><mo>∧</mo><mi>p</mi><msup><mi>g</mi><mi>'</mi></msup><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>p</mi><mi>g</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math></simpara>
-</listitem>
-</itemizedlist>
-<blockquote>
-<simpara>It is a SyntaxError if the Identifier <literal>eval</literal> or the Identifier <literal>arguments</literal> occurs as the Identifier in a <literal>PropertySetParameterList</literal> of a <literal>PropertyAssignment</literal> that is contained in strict code or if its
-<literal>FunctionBody</literal> is strict code. [<link linkend="ECMA11a">ECMA11a(p.p.66)</link>]</simpara>
-</blockquote>
-<itemizedlist>
-<listitem>
-<simpara>If two or more property assignments have the same name (and the previous conditions hold), then the types of these assignments must <emphasis>conform</emphasis>.
-That is to say that the inferred (but not declared) type of all assignments must be type of probably declared types and if the types are explicitly declared, they must be equal.</simpara>
-</listitem>
-<listitem>
-<simpara>In N4JS mode, the name of a property must be a valid N4JSIdentifier:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>m</mi><mi>o</mi><mi>d</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>n4js</mtext></mstyle><mo>→</mo><mspace width="3.0mm"/><mo>∀</mo><mi>p</mi><mi>a</mi><mo>∈</mo><mi>o</mi><mi>l</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>s</mi><mi>:</mi></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mrow><mi>p</mi><mi>a</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>N4JSIdentifier</mtext></mstyle></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-22501">
-<title>Superfluous properties of an object literal</title>
-<simpara>
-<anchor xml:id="Req-IDE-22501" xreflabel="[Req-IDE-22501]"/>
-<emphasis role="strong">Requirement: IDE-22501:</emphasis>
-<link linkend="Req-IDE-22501">Superfluous properties of an object literal</link> (ver. 1)</simpara>
- <simpara>
-
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math> be the expected type of an object literal <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>O</mi></math> as defined by the context in which <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>O</mi></math> is used.
-If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math> is not type <literal>Object</literal> and not dynamic, then the compiler creates a warning <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>O</mi></math> contains properties not found in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math>.</simpara>
-<simpara>This is true in particular for object literals passed in as arguments of a spec-constructor.</simpara>
-</requirement>
-</section>
-<section xml:id="_scoping-and-linking">
-<title>Scoping and linking</title>
-<example>
-<title>Scoping and linking</title>
-<programlisting language="n4js" linenumbering="unnumbered">var p = {
- f: function() {
- console.log("p´s f");
- },
- b: function() {
- this.f();
- },
- o: {
- nested: "Hello"
- }
-};
-p.b();
-p.o.nested;</programlisting>
-<itemizedlist>
-<listitem>
-<simpara>Other properties within an object literal property can be accessed using this.
-In the expression of property name value pairs, however, <literal>this</literal> is not be bound to the containing object literal, but usually to undefined or global.</simpara>
-</listitem>
-<listitem>
-<simpara>The properties of an object literal are accessible from outside.</simpara>
-</listitem>
-<listitem>
-<simpara>Nested properties of an object literal are also accessible from outside.</simpara>
-</listitem>
-</itemizedlist>
-</example>
-<bridgehead xml:id="type-inference-3" renderas="sect4">Type Inference</bridgehead>
-<simpara>An object literal implicitly extends <literal>~Object</literal>, therefore, object literal types use structural typing.
-For details see <xref linkend="_structural-typing"/>.
-From a type systems point of view, the two variables <literal>ol</literal> and <literal>st</literal> below have the same type.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var ol = {
- s: "hello",
- n: 42
-}
-var st: ~Object with { s: string; n: number;};</programlisting>
-</section>
-</section>
-<section xml:id="_parenthesized-expression-and-grouping-operator">
-<title>Parenthesized Expression and Grouping Operator</title>
-<simpara>The grouping operator is defined here as a parenthesized expression.</simpara>
-<bridgehead xml:id="parenthesized-expression-grouping-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>cf. [<link linkend="ECMA11a">ECMA11a(p.S11.1.6, p.p.67)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ParenExpression <Yield>: '(' expression=Expression<In=true,Yield> ')';</programlisting>
-<bridgehead xml:id="Grouping-Operator-type-inference" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type of the grouping operator simply is the type of its nested expression.
-The type if a parenthesized expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mi>e</mi></math> is inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>:</mi><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>’(’</mtext></mstyle><mi>e</mi><mstyle mathvariant="monospace"><mtext>’)’</mtext></mstyle><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-<example>
-<title>Parenthesized Expression Type Examples</title>
-<simpara>In the following listing, the type of the plain expressions is equivalent to the parenthesized versions:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A{} class B extends A{}
-var f: boolean; var a: A a; var b: B;
-
-/* simple <-> parenthesized */
-10; (10);
-"hello"; ("hello");
-true; (true);
-a; (a);
-10-5; (10-5);
-f?a:b (f?a:b);</programlisting>
-</example>
-</section>
-<section xml:id="_property-accessors">
-<title>Property Accessors</title>
-<bridgehead xml:id="property-accessor-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Property accessors in N4JS are based on [<link linkend="ECMA11a">ECMA11a(p.S11.2.1, p.p.67ff)</link>].
-They cannot only be used for accessing properties of an object, but also for accessing members of a class instance.
-In order to support parameterized calls, the syntax is extended to optionally allow type arguments.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ParameterizedPropertyAccessExpression:
- target=PrimaryExpression<Yield> ParameterizedPropertyAccessExpressionTail<Yield>
-;
-
-IndexedAccessExpression:
- target=PrimaryExpression<Yield> IndexedAccessExpressionTail<Yield>
-;
-
-fragment IndexedAccessExpressionTail <Yield>*:
- '[' index=Expression<In=true,Yield> ']'
-;
-
-fragment ParameterizedPropertyAccessExpressionTail <Yield>*:
- '.' TypeArguments? property=[types::IdentifiableElement|IdentifierName]
-;</programlisting>
-<simpara>Note that in [<link linkend="ECMA11a">ECMA11a</link>], the <literal>index access</literal> is called <literal><emphasis>bracket notation</emphasis></literal>.</simpara>
-<bridgehead xml:id="property-access-direct" renderas="sect4">Direct Property Access</bridgehead>
-<simpara>We define a special case of property access as follows:</simpara>
-<definition>
-<title>Direct Property Access</title>
-<simpara>
-<anchor xml:id="direct_property_access" xreflabel="[direct_property_access]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="direct_property_access">Direct Property Access</link></simpara>
-<simpara>
-
-A property access expression is called <emphasis>direct</emphasis>, iff</simpara>
-<itemizedlist>
-<listitem>
-<simpara>its target is an identifier reference to a class, interface, enum, or the built-in object <literal>Symbol</literal>, and</simpara>
-</listitem>
-<listitem>
-<simpara>its property name denotes an <emphasis>owned</emphasis> member of the target classifier (not an inherited, consumed, or polyfilled member) or a literal if the target is an enum.</simpara>
-</listitem>
-</itemizedlist>
-</definition>
-<simpara>As a consequence, a direct property access can only refer to static members.</simpara>
-<simpara>The first requirement of the above definition rules out property access expressions that do not directly point to their target classifier or enum, as shown in the following example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- const field = 'hello';
-}
-C.field; // direct property access to 'field'
-let ctor = C;
-ctor.field; // *not* a direct property access to 'field'</programlisting>
-<simpara>Direct property access is the only form of property access allowed in compile-time expressions, cf. <xref linkend="compile-time-expressions"/>.</simpara>
-<section xml:id="properties-1">
-<title>Properties</title>
-<simpara>We define the following properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>target</literal> </term>
-<listitem>
-<simpara>The receiver of the property access.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>index</literal> </term>
-<listitem>
-<simpara>The index expression in case of an IndexedAccessExpression (returns <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></math> otherwise).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>property</literal> </term>
-<listitem>
-<simpara>The name of the property in case of non-indexed-access expressions (returns <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></math> otherwise, although the index may be interpreted as property name).</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>We define the following pseudo properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>isDotAccess</literal> </term>
-<listitem>
-<simpara>Read-only boolean property, returns true for non-index access expression (similar to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>p</mi></mfenced><mo>≠</mo><mstyle mathvariant="monospace"><mtext>IndexedAccessExpression</mtext></mstyle></math>).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>isIndexAccess</literal> </term>
-<listitem>
-<simpara>Read-only boolean property, returns true for index access expression (similar to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>p</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>IndexedAccessExpression</mtext></mstyle></math>.<?asciidoc-br?>
-The equation <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>D</mi><mi>o</mi><mi>t</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mo>=</mo><mo>¬</mo><mi>p</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>I</mi><mi>n</mi><mi>d</mi><mi>e</mi><mi>x</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi></math> is always true.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>name</literal> </term>
-<listitem>
-<simpara>Returns the name of the property.
-This is either the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi></math> converted to a simple name or the index converted to a name (where possible) if it is an indexed-accessed expression.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="property-acessors-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>The parameterization is part of the property access in case of generic methods.
-For generic functions, a parameterized function call is introduced (cf. <xref linkend="_function-calls"/>).
-The constraints are basically similar.</simpara>
-<requirement xml:id="IDE-97">
-<title>Property Access and Dot Notation</title>
-<simpara>
-<anchor xml:id="Req-IDE-97" xreflabel="[Req-IDE-97]"/>
-<emphasis role="strong">Requirement: IDE-97:</emphasis>
-<link linkend="Req-IDE-97">Property Access and Dot Notation</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>If dot notation is used in N4JS mode, the referenced property must exist unless receiver is a dynamic type:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>D</mi><mi>o</mi><mi>t</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mo>∧</mo><mo>¬</mo><mi>R</mi><mo>.</mo><mi>d</mi><mi>y</mi><mi>n</mi><mo>→</mo><mtext>
-</mtext><mspace width="3.0mm"/><mo>∃</mo><mi>m</mi><mo>∈</mo><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>i</mi><mi>e</mi><mi>s</mi><mi>:</mi><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></math>
-</listitem>
-<listitem>
-<simpara>If dot notation is used and the referenced property exists, then the property must be accessible:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>D</mi><mi>o</mi><mi>t</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mo>∧</mo><mo>¬</mo><mi>R</mi><mo>.</mo><mi>d</mi><mi>y</mi><mi>n</mi><mo>→</mo><mtext>
-</mtext><mspace width="3.0mm"/><mfenced close=")" open="("><mrow><mo>∃</mo><mi>m</mi><mo>∈</mo><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>i</mi><mi>e</mi><mi>s</mi><mi>:</mi><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mrow></mfenced><mo>→</mo><mi>α</mi><mfenced close=")" open="("><mrow><mi>p</mi><mi>a</mi><mi>e</mi></mrow><mi>m</mi></mfenced></math>
-</listitem>
-<listitem>
-<simpara>If dot notation is used and the referenced property exists and this property is a member with a declared <literal>@This</literal> type (only possible for methods or field accessors),
-then the receiver must be a subtype of the declared <literal>@This</literal> type.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-98">
-<title>Index Access</title>
-<simpara>
-<anchor xml:id="Req-IDE-98" xreflabel="[Req-IDE-98]"/>
-<emphasis role="strong">Requirement: IDE-98:</emphasis>
-<link linkend="Req-IDE-98">Index Access</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>An index access expression is valid iff one of the following cases applies:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>the receiver is of a dynamic type. In this case, the index may be any expression (need not be a compile-time expression).</simpara>
-</listitem>
-<listitem>
-<simpara>the receiver is an immediate instance of <literal>Object</literal>, i.e. it is a subtype of <literal>Object</literal> and its super types but <emphasis role="strong">not</emphasis> of any other type including <literal>~Object</literal> and <literal>~~Object</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>the receiver is of type Array, ArgumentType, string, or String (including their subtypes) <emphasis role="strong">and</emphasis> the index is an expression of type <literal>number</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>the index expression is a compile-time expression</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis role="strong">and</emphasis> the receiver type defines a member with a name equal to the string representation of the index expression’s compile-time value<?asciidoc-br?></simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">and</emphasis> the receiver is not an enum.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Although index access is very limited, it is still possible to use immediate instances of <literal>Object</literal> in terms of a map (but this applies only to index access, not the dot notation):</simpara>
-<example>
-<title>Object as Map</title>
-<programlisting language="n4js" linenumbering="unnumbered">var map: Object = new Object();
-map["Kant"] = "Imperative";
-map["Hegel"] = "Dialectic";
-map.spinoza = "Am I?"; // error: Couldn't resolve reference to IdentifiableElement 'spinoza'.</programlisting>
-</example>
-<requirement xml:id="IDE-99">
-<title>Parameterized Property Access</title>
-<simpara>
-<anchor xml:id="Req-IDE-99" xreflabel="[Req-IDE-99]"/>
-<emphasis role="strong">Requirement: IDE-99:</emphasis>
-<link linkend="Req-IDE-99">Parameterized Property Access</link> (ver. 1)</simpara>
- <simpara>
-
-For a parameterized property access expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mi>a</mi><mi>e</mi></math>, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The receiver or target must be a function or method:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>Function</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara>The number of type arguments must match the number of type parameters of the generic function or method:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo><mo>=</mo><mo>|</mo><mi>p</mi><mi>a</mi><mi>e</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>V</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo></math></simpara>
-</listitem>
-<listitem>
-<simpara>The type arguments of a parameterized property access expression must be subtypes of the boundaries of the parameters of the called generic method.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Also see constraints on read (<xref linkend="Req-IDE-93"/>) and write (<xref linkend="Req-IDE-121"/>) access.</simpara>
-</requirement>
-<bridgehead xml:id="type-inference-5" renderas="sect4">Type Inference</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S11.2.1, p.p.67ff)</link>]</simpara>
-<simpara>We define the following type inferencing rules for property accessors:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The type of an indexed-access expression <emphasis>p</emphasis> is inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><mo>¬</mo><mi>p</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>d</mi><mi>y</mi><mi>n</mi><mo>∨</mo><mi>p</mi><mo>.</mo><mi>i</mi><mi>n</mi><mi>d</mi><mi>e</mi><mi>x</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mfenced close="]" open="["><mrow><mi>n</mi><mi>u</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi></mrow></mfenced><mspace width="3.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>p</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>Array</mtext></mstyle><mo><</mo><mstyle mathvariant="monospace"><mtext>T</mtext></mstyle><mo>></mo></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>p</mi><mi>:</mi><mi>T</mi></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>e</mi><mi>l</mi><mi>s</mi><mi>e</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>p</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara>The type of a property access expression is inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><mi>Γ</mi><mo>←</mo><mi>θ</mi><mfenced close=")" open="("><mi>R</mi></mfenced><mo>⊢</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mi>:</mi><mi>R</mi><mspace width="3.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>:</mi><mi>T</mi></mrow><mrow><mstyle mathvariant="monospace"><mtext>PropertyAccessExpression</mtext></mstyle><mi> </mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>:</mi><mi>T</mi></mrow></mfrac></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara>The type of a parameterized access expression <emphasis>p</emphasis> is inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><mo>∃</mo><mi>m</mi><mo>∈</mo><mi>p</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mi>:</mi><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>p</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mspace width="3.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>m</mi><mi>:</mi><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>p</mi><mi>:</mi><mi>T</mi></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>p</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-<section xml:id="_new-expression">
-<title>New Expression</title>
-<simpara>cf. [<link linkend="ECMA11a">ECMA11a(p.S11.2.2, p.p.68)</link>]</simpara>
-<bridgehead xml:id="new-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<programlisting language="xtext" linenumbering="unnumbered">NewExpression: 'new' callee=MemberExpression<Yield> (-> TypeArguments)?
- (=> withArgs?='(' Arguments<Yield>? ')' )?</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">import Address from "my/Address";
-
-var a = new Address();
-// a.type := my/Address
-
-class C<T> {
- constructor(param: T) {}
-}
-var c = new C<string>("hello");</programlisting>
-<bridgehead xml:id="new-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-100">
-<title>New expression</title>
-<simpara>
-<anchor xml:id="Req-IDE-100" xreflabel="[Req-IDE-100]"/>
-<emphasis role="strong">Requirement: IDE-100:</emphasis>
-<link linkend="Req-IDE-100">New expression</link> (ver. 1)</simpara>
- <simpara>
-
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mi>e</mi></math> be a new expression, with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>⊢</mo><mi>n</mi><mi>e</mi><mo>.</mo><mi>c</mi><mi>a</mi><mi>l</mi><mi>l</mi><mi>e</mi><mi>e</mi><mi>:</mi><mi>C</mi></math>.
-The following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><anchor xml:id="new-expression-1" xreflabel="[new-expression-1]"/> The callee must be a constructor type: <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo><</mo><mi>:</mi><mstyle mathvariant="monospace"><mtext>constructor</mtext></mstyle><mfenced close="}" open="{"><mi>?</mi></mfenced></math> or a constructable type.</simpara>
-</listitem>
-<listitem>
-<simpara><anchor xml:id="new-expression-2" xreflabel="[new-expression-2]"/> Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>O</mi></math> be the type argument of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math>, that is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>=</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mfenced close="}" open="{"><mi>O</mi></mfenced></math>. In that case,</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>O</mi></math> must not be an interface or enum: <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mi>C</mi></mfenced><mo>∉</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>Interface</mtext></mstyle><mstyle mathvariant="monospace"><mtext>Enum</mtext></mstyle></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>O</mi></math> must not contain any wildcards.</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>O</mi></math> must not be a type variable.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara><anchor xml:id="new-expression-3" xreflabel="[new-expression-3]"/> If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> is not a constructor type, it must be a constructable type, that is one of the following:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close="}" open="{"><mtable><mtr><mtd><mstyle mathvariant="monospace"><mtext>Object, Function, String, Boolean,</mtext></mstyle></mtd></mtr><mtr><mtd><mstyle mathvariant="monospace"><mtext>Number, Array, Date, RegExp, Error</mtext></mstyle></mtd></mtr></mtable></mfenced></math>
-<simpara>In particular, it must not refer to a primitive type or a defined
-functions (i.e., subtypes of <literal>Function</literal>) cannot be used in new-expressions in
-N4JS.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Remarks:</simpara>
-<simpara>to <link linkend="new-expression-1">1</link> The type of an abstract class <literal>A</literal> is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mfenced close="}" open="{"><mi>A</mi></mfenced></math>.
-Or in other words: Only instantiable classes have an inferred type of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mfenced close="}" open="{"><mrow><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/><mo>.</mo><mspace width="1.0mm"/></mrow></mfenced></math>.</simpara>
-<simpara>to <link linkend="new-expression-2">2</link> Even though it is possible to use the constructor type of an abstract class – concrete subclasses with override compatible constructor signature will be subclasses of this constructor.</simpara>
-<simpara>to <link linkend="new-expression-3">3</link> It is not possible to refer to union or intersection at that location. So this is not explicitly denied here since it is not possible anyway.</simpara>
-<example>
-<title>Abstract classes and construction</title>
-<simpara>The following examples demonstrates the usage of abstract classes and constructor types, to make the first two constraints more clearer:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/* XPECT_SETUP org.eclipse.n4js.spec.tests.N4JSSpecTest END_SETUP */
-
-abstract class A {}
-class B extends A {}
-
-// XPECT errors --> "Cannot instantiate abstract class A." at "A"
-var x = new A();
-// XPECT noerrors -->
-var y = new B();
-
-function foo(ctor : constructor{A}) {
- // XPECT noerrors -->
- return new ctor();
-}
-
-// XPECT errors --> "type{A} is not a subtype of constructor{A}." at "A"
-foo(A);
-// XPECT noerrors -->
-foo(B);</programlisting>
-</example>
-<bridgehead xml:id="type-inference-6" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type of a new expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mi>e</mi></math> is inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>n</mi><mi>e</mi><mo>.</mo><mi>c</mi><mi>a</mi><mi>l</mi><mi>l</mi><mi>e</mi><mi>e</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>constructor</mtext><mtext>C</mtext></mstyle></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>n</mi><mi>e</mi><mi>:</mi><mi>C</mi></mrow></mfrac></math>
-<simpara>For classes, constructors are described in <xref linkend="_constructor-and-classifier-type"/>.</simpara>
-<simpara>In N4JS it is not allowed to call new on a plain function.
-For example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">function foo() {}
-var x = new foo();</programlisting>
-<simpara>will issue an error.</simpara>
-</section>
-<section xml:id="_function-expression-2">
-<title>Function Expression</title>
-<simpara>See <xref linkend="_functions"/> for details.</simpara>
-</section>
-<section xml:id="_function-calls">
-<title>Function Calls</title>
-<simpara>In N4JS, a function call [<link linkend="ECMA11a">ECMA11a(p.S11.2.3)</link>] is similar to a method call.
-Additionally to the ECMAScript’s CallExpression, a ParameterizedCallExpression is introduced to allow type arguments passed to plain functions.</simpara>
-<bridgehead xml:id="_syntax-12" renderas="sect4">Syntax</bridgehead>
-<literallayout class="monospaced">[[function-calls-syntax]]</literallayout>
-<simpara>Similar to [<link linkend="ECMA11a">ECMA11a(p.S11.2.3, p.p.68ff)</link>], a function call is defined as follows:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">CallExpression <Yield>:
- target=IdentifierRef<Yield>
- ArgumentsWithParentheses<Yield>
-;
-
-ParameterizedCallExpression <Yield>:
- TypeArguments
- target=IdentifierRef<Yield>
- ArgumentsWithParentheses<Yield>
-;
-
-fragment ArgumentsWithParentheses <Yield>*:
- '(' Arguments<Yield>? ')'
-;
-
-fragment Arguments <Yield>*:
- arguments+=AssignmentExpression<In=true,Yield> (',' arguments+=AssignmentExpression<In=true,Yield>)* (',' spread?='...' arguments+=AssignmentExpression<In=true,Yield>)?
- | spread?='...' arguments+=AssignmentExpression<In=true,Yield>
-;</programlisting>
-<bridgehead xml:id="function-calls-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-101">
-<title>Function Call Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-101" xreflabel="[Req-IDE-101]"/>
-<emphasis role="strong">Requirement: IDE-101:</emphasis>
-<link linkend="Req-IDE-101">Function Call Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given call expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> bound to a method or function declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If less arguments are provided than formal parameters were declared, the missing formal parameters must have been declared optional:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>f</mi><mo>.</mo><mi>a</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo><mo><</mo><mo>|</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>→</mo><mo>∀</mo><mo>|</mo><mi>f</mi><mo>.</mo><mi>a</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo><mo><</mo><mi>i</mi><mo>≤</mo><mo>|</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mi>:</mi><msub><mi>F</mi><mi>p</mi></msub><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>i</mi></msub><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>a</mi><mi>l</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>If more arguments are provided than formal parameters were declared, the last formal parameter must have been declared variadic:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>|</mo><mi>f</mi><mo>.</mo><mi>a</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo><mo>></mo><mo>|</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>→</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mrow><mo>|</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>-</mo><mn>1</mn></mrow></msub><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>i</mi><mi>a</mi><mi>d</mi><mi>i</mi><mi>c</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>Types of provided arguments must be subtypes of the formal parameter types:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mn>0</mn><mo><</mo><mi>i</mi><mo><</mo><mi>m</mi><mi>i</mi><mi>n</mi><mfenced close=")" open="("><mrow><mo>|</mo><mi>f</mi><mo>.</mo><mi>a</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo></mrow><mrow><mo>|</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo></mrow></mfenced><mi>:</mi><mi>f</mi><mo>.</mo><mi>a</mi><mi>r</mi><mi>g</mi><msub><mi>s</mi><mi>i</mi></msub><mo><</mo><mi>:</mi><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>i</mi></msub></math></simpara>
-</listitem>
-<listitem>
-<simpara>If more arguments are provided than formal parameters were declared, the type of the exceeding arguments must be a subtype of the last (variadic) formal parameter type:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mo>|</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo><</mo><mi>i</mi><mo>≤</mo><mo>|</mo><mi>f</mi><mo>.</mo><mi>a</mi><mi>r</mi><mi>g</mi><mi>s</mi><mo>|</mo><mi>:</mi><mi>f</mi><mo>.</mo><mi>a</mi><mi>r</mi><mi>g</mi><msub><mi>s</mi><mi>i</mi></msub><mo><</mo><mi>:</mi><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mrow><mo>|</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>-</mo><mn>1</mn></mrow></msub></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-102">
-<title>Parameterized Function Call Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-102" xreflabel="[Req-IDE-102]"/>
-<emphasis role="strong">Requirement: IDE-102:</emphasis>
-<link linkend="Req-IDE-102">Parameterized Function Call Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-* The number of type arguments in a parameterized call expression must be equal to the number of type parameters of the generic function / method and the
-type arguments must be subtypes of the corresponding declared upper boundaries of the type parameters of the called generic function.</simpara>
-<simpara>Note that (for a limited time), constraints <xref linkend="Req-IDE-101"/> and <xref linkend="Req-IDE-102"/> are not applied if the the type of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> is <literal>Function</literal>.
-See <xref linkend="_function-object-type"/>.</simpara>
-</requirement>
-<bridgehead xml:id="type-inference-7" renderas="sect4">Type Inference</bridgehead>
-<simpara>A call expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi></math> is bound to a method (<xref linkend="_methods"/>) or function declaration (which may be part of a function definition
-(<xref linkend="_function-declaration"/> or specified via a function type <xref linkend="_function-type"/>) <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> (via evaluation of <literal>MemberExpression</literal>.
-The type of the call is inferred from the function declaration or type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mrow><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi></mrow><mi>F</mi></mfenced><mspace width="3.0mm"/><mi>F</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-<simpara>A generic method invocation may be parameterized as well.
-This is rarely required as the function argument types are usually inferred from the given arguments.
-In some cases, for instance with pathSelectors, this is useful.
-In that case, the type variable defined in the generic method declaration is explicitly bound to types by using type arguments.
-See <xref linkend="_property-accessors"/> for semantics and type inference.</simpara>
-<example>
-<title>Generic Method Invocation</title>
-<simpara>This examples demonstrate how to explicitly
-define the type argument in a method call in case it cannot be inferred
-automatically.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class C {
- static <T> foo(p: pathSelector<T>): void {..}
-};
-C.<my.Address>foo("street.number");</programlisting>
-<simpara>Note that in many cases, the type inferencer should be able to infer the type automatically.
-For example, for a method</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">function <T> bar(c: T, p: pathSelector<T>): void {..};</programlisting>
-<simpara>and a function call</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">bar(context, "some.path.selector");
-[source,n4js]</programlisting>
-<simpara>the type variable <literal>T</literal> can be automatically bound to the type of variable <literal>context</literal>.</simpara>
-</example>
-</section>
-<section xml:id="_postfix-expression">
-<title>Postfix Expression</title>
-<bridgehead xml:id="postfix-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<programlisting language="xtext" linenumbering="unnumbered">PostfixExpression returns Expression: LeftHandSideExpression
- (=>({PostfixExpression.expression=current} /* no line terminator here */ op=PostfixOperator))?
- ;
-enum PostfixOperator: inc='++' | dec='--';</programlisting>
-<bridgehead xml:id="semantics-and-type-inference" renderas="sect4">Semantics and Type Inference</bridgehead>
-<simpara>The type inference and constraints for postfix operators <literal>++</literal> and <literal>--</literal>, cf. [<link linkend="ECMA11a">ECMA11a(p.S11.3.1, p.p.70)</link>], [<link linkend="ECMA11a">ECMA11a(p.S11.3.1, p.p.70)</link>],
-are defined similarly to their prefix variants (unary expressions), see <xref linkend="_unary-expression"/>.</simpara>
-<requirement xml:id="IDE-103">
-<title>Postfix Expression Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-103" xreflabel="[Req-IDE-103]"/>
-<emphasis role="strong">Requirement: IDE-103:</emphasis>
-<link linkend="Req-IDE-103">Postfix Expression Constraints</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For a given postfix expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>∈</mo><mfenced close="}" open="{"><mrow><mo>+</mo><mo>+</mo></mrow><mrow><mo>-</mo><mo>-</mo></mrow></mfenced></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>T</mi></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>In N4JS mode, the type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> of the expression must be a number.</simpara>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>=</mo><mi>P</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mspace width="0.278em"/><mi>p</mi><mi>a</mi><mfenced close=")" open="("><mi>p</mi></mfenced><mo>∧</mo><mi>p</mi><mi>a</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>D</mi><mi>o</mi><mi>t</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mo>→</mo></math> both <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>g</mi><mi>e</mi><mi>t</mi></math> <emphasis>p</emphasis> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>e</mi><mi>t</mi></math> <emphasis>p</emphasis> must be defined.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-</section>
-<section xml:id="_unary-expression">
-<title>Unary Expression</title>
-<bridgehead xml:id="unary-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>We define the following unary operators and expression, similar to [<link linkend="ECMA11a">ECMA11a(p.p.70ff)</link>]:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">UnaryExpression returns Expression:
- PostfixExpression
- | ({UnaryExpression} op=UnaryOperator expression=UnaryExpression);
-enum UnaryOperator: delete | void | typeof | inc='++' | dec='--' | pos='+' | neg='-' | inv='$\sim$' | not='!';</programlisting>
-<bridgehead xml:id="unary-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>For semantics of the delete operator, see also [<link linkend="MozillaJSRef">MozillaJSRef</link>]</simpara>
-<requirement xml:id="IDE-104">
-<title>Delete Operator Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-104" xreflabel="[Req-IDE-104]"/>
-<emphasis role="strong">Requirement: IDE-104:</emphasis>
-<link linkend="Req-IDE-104">Delete Operator Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given unary expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>delete</mtext></mstyle></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>In strict mode, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></math> must be a reference to a property of an object literal, a member of a class type, or to a property of the global type
-(i.e., the reference must be bound, and the bound target must not be a variable).</simpara>
-</listitem>
-<listitem>
-<simpara>In N4JS mode, the referenced property or member must not be declared in the containing type and the containing type reference must be declared dynamic.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-105">
-<title>Void Operator Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-105" xreflabel="[Req-IDE-105]"/>
-<emphasis role="strong">Requirement: IDE-105:</emphasis>
-<link linkend="Req-IDE-105">Void Operator Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-There are no specific constraints defined for with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle></math></simpara>
-</requirement>
-<requirement xml:id="IDE-106">
-<title>Typeof Operator Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-106" xreflabel="[Req-IDE-106]"/>
-<emphasis role="strong">Requirement: IDE-106:</emphasis>
-<link linkend="Req-IDE-106">Typeof Operator Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-There are no specific constraints defined for unary expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>typeof</mtext></mstyle></math>.</simpara>
-</requirement>
-<requirement xml:id="IDE-107">
-<title>Increment/Decrement Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-107" xreflabel="[Req-IDE-107]"/>
-<emphasis role="strong">Requirement: IDE-107:</emphasis>
-<link linkend="Req-IDE-107">Increment/Decrement Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given unary expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>∈</mo><mfenced close="}" open="{"><mrow><mo>+</mo><mo>+</mo></mrow><mrow><mo>-</mo><mo>-</mo></mrow></mfenced></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>T</mi></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If mode is N4JS, the type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math> of the expression must be a number</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>UnaryExpression</mtext></mstyle><mo>⊲</mo><mstyle mathvariant="monospace"><mtext>Expression</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>=</mo><mi>P</mi><mi>r</mi><mi>o</mi><mi>p</mi><mi>e</mi><mi>r</mi><mi>t</mi><mi>y</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mspace width="0.278em"/><mi>p</mi><mi>a</mi><mfenced close=")" open="("><mi>p</mi></mfenced><mo>∧</mo><mi>p</mi><mi>a</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>D</mi><mi>o</mi><mi>t</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>→</mo></math> both <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>g</mi><mi>e</mi><mi>t</mi></math> <emphasis>p</emphasis> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>e</mi><mi>t</mi></math> <emphasis>p</emphasis> must be defined.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-108">
-<title>Unary Plus/Minus/Bitwise Not Operator Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-108" xreflabel="[Req-IDE-108]"/>
-<emphasis role="strong">Requirement: IDE-108:</emphasis>
-<link linkend="Req-IDE-108">Unary Plus/Minus/Bitwise Not Operator Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given unary expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>∈</mo><mfenced close="}" open="{"><mo>+</mo><mo>-</mo><mo>∼</mo></mfenced></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>T</mi></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>In N4JS mode, the type T of the expression must be a number:</simpara>
-</listitem>
-</itemizedlist>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>UnaryExpression</mtext></mstyle><mo>⊲</mo><mstyle mathvariant="monospace"><mtext>Expression</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac></math>
-</requirement>
-<requirement xml:id="IDE-109">
-<title>Logical Not Operator Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-109" xreflabel="[Req-IDE-109]"/>
-<emphasis role="strong">Requirement: IDE-109:</emphasis>
-<link linkend="Req-IDE-109">Logical Not Operator Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-There are no specific constraints defined for with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>u</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>!</mtext></mstyle></math>.</simpara>
-</requirement>
-<bridgehead xml:id="type-inference-8" renderas="sect4">Type Inference</bridgehead>
-<simpara>The following operators have fixed types independent of their operand types:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>’delete’</mtext></mstyle><mi> </mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>boolean</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>’void’</mtext></mstyle><mi> </mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>undefined</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>’typeof’</mtext></mstyle><mi> </mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>(’++’—’–’—’+’—’-’—’ ’)</mtext></mstyle><mi> </mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>’!’</mtext></mstyle><mi> </mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>boolean</mtext></mstyle></mrow></mfrac></math></simpara>
-</section>
-<section xml:id="_multiplicative-expression">
-<title>Multiplicative Expression</title>
-<bridgehead xml:id="multiplicative-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.p.73ff)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">MultiplicativeExpression returns Expression: UnaryExpression
- (=>({MultiplicativeExpression.lhs=current} op=MultiplicativeOperator) rhs=UnaryExpression)*;
-enum MultiplicativeOperator: times='*' | div='/' | mod='%';</programlisting>
-<bridgehead xml:id="multiplicative-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-110">
-<title>Multiplicative Expression Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-110" xreflabel="[Req-IDE-110]"/>
-<emphasis role="strong">Requirement: IDE-110:</emphasis>
-<link linkend="Req-IDE-110">Multiplicative Expression Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given multiplicative expression the following constraints must hold in N4JS mode :</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The types of the operands may be any type:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>MultiplicativeExpression</mtext></mstyle><mo>⊲</mo><mstyle mathvariant="monospace"><mtext>Expression</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac><mrow/></math>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>If a non-numeric operand is used, the result may be <literal>NaN</literal> which actually is a number as well.</simpara>
-<bridgehead xml:id="_type-inference-6" renderas="sect4">Type Inference</bridgehead>
-<literallayout class="monospaced">[[type-inference-9]]</literallayout>
-<simpara>The inferred type of a multiplicative expression always is number:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>MultiplicativeExpression</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac></math>
-</section>
-<section xml:id="_additive-expression">
-<title>Additive Expression</title>
-<bridgehead xml:id="additive-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.p.75ff)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">AdditiveExpression returns Expression: MultiplicativeExpression
- (=>({AdditiveExpression.lhs=current} op=AdditiveOperator) rhs=MultiplicativeExpression)*;
-enum AdditiveOperator: add='+' | sub='-';</programlisting>
-<bridgehead xml:id="additive-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-111">
-<title>Additive Expression Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-111" xreflabel="[Req-IDE-111]"/>
-<emphasis role="strong">Requirement: IDE-111:</emphasis>
-<link linkend="Req-IDE-111">Additive Expression Constraints</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For a given additive expression the following constraints must hold in N4JS mode:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The type of the operand can be any type:</simpara>
-</listitem>
-</itemizedlist>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>AdditiveExpression</mtext></mstyle><mi> </mi><mi>e</mi><mo>⊲</mo><mstyle mathvariant="monospace"><mtext>Expression</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-</requirement>
-<simpara>In JavaScript it is possible to subtract two non-numerics, leading to <literal>NaN</literal>. Also <literal>undefined</literal> or <literal>null</literal> may be used. The real difference is what type is to be returned (string or number, see below).</simpara>
-<section xml:id="type-inference-10">
-<title>Type Inference</title>
-<simpara role="language-n4js">The type of an additive expression is usually inferred to <literal>number</literal>, except for addition which may lead to string as well.
-The result for the addition operator is only be a number if both operands are numbers, booleans, null, or undefined.
-Using <literal>undefined</literal> in an additive expression leads to <literal>NaN</literal> which actually is a number from the type system’s point of view. Additional analysis may create errors in the latter case though.</simpara>
-<simpara>We first define two helper rules to simplify the addition operator condition:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><mo>∃</mo><mi>N</mi><mi>i</mi><mi>n</mi><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>number, int, boolean, null, undefined</mtext></mstyle></mfenced><mi>:</mi><mi>T</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mo>=</mo><mi>N</mi></mrow><mrow><mi>n</mi><mi>b</mi><mfenced close=")" open="("><mi>T</mi></mfenced></mrow></mfrac><mstyle mathvariant="monospace"><mtext>nb</mtext></mstyle></mtd></mtr><mtr><mtd><mfrac><mrow><mi>n</mi><mi>b</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>∨</mo><mi> </mi><mrow><mo>(</mo><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Union</mtext></mstyle><mi> </mi><mo>∧</mo><mi> </mi><mo>∃</mo><mi> </mi><mi>E</mi><mo>∈</mo><mi>T</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>m</mi><mi>n</mi><mi>b</mi><mfenced close=")" open="("><mi>E</mi></mfenced></mrow></mrow><mrow><mi>m</mi><mi>n</mi><mi>b</mi><mfenced close=")" open="("><mi>T</mi></mfenced></mrow></mfrac><mstyle mathvariant="monospace"><mtext>mnb</mtext></mstyle></mtd></mtr><mtr><mtd><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mo>.</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>L</mi><mspace width="3.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mo>.</mo><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>R</mi><mspace width="3.0mm"/><mi>n</mi><mi>b</mi><mfenced close=")" open="("><mi>L</mi></mfenced><mspace width="3.0mm"/><mi>n</mi><mi>b</mi><mfenced close=")" open="("><mi>R</mi></mfenced></mrow><mrow><mi>t</mi><mi>o</mi><mi>N</mi><mi>u</mi><mi>m</mi><mfenced close=")" open="("><mrow><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi></mrow></mfenced></mrow></mfrac><mstyle mathvariant="monospace"><mtext>toNum</mtext></mstyle></mtd></mtr><mtr><mtd><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mo>.</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>L</mi><mspace width="3.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mo>.</mo><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>R</mi><mspace width="3.0mm"/><mi>m</mi><mi>n</mi><mi>b</mi><mfenced close=")" open="("><mi>L</mi></mfenced><mspace width="3.0mm"/><mi>m</mi><mi>n</mi><mi>b</mi><mfenced close=")" open="("><mi>R</mi></mfenced></mrow><mrow><mi>m</mi><mi>a</mi><mi>y</mi><mi>N</mi><mi>u</mi><mi>m</mi><mfenced close=")" open="("><mrow><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi></mrow></mfenced></mrow></mfrac><mstyle mathvariant="monospace"><mtext>mayNum</mtext></mstyle></mtd></mtr></mtable></math>
-<simpara>The type of an additive expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> is inferred as follows:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mfrac><mrow><mi>e</mi><mo>.</mo><mi>o</mi><mi>p</mi><msup><mo>=</mo><mi>'</mi></msup><msup><mo>+</mo><mi>'</mi></msup><mspace width="3.0mm"/><mo>¬</mo><mi>t</mi><mi>o</mi><mi>N</mi><mi>u</mi><mi>m</mi><mfenced close=")" open="("><mi>e</mi></mfenced><mspace width="3.0mm"/><mo>¬</mo><mi>m</mi><mi>a</mi><mi>y</mi><mi>N</mi><mi>u</mi><mi>m</mi><mfenced close=")" open="("><mi>e</mi></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>e</mi><mo>.</mo><mi>o</mi><mi>p</mi><msup><mo>=</mo><mi>'</mi></msup><msup><mo>+</mo><mi>'</mi></msup><mspace width="3.0mm"/><mo>¬</mo><mi>t</mi><mi>o</mi><mi>N</mi><mi>u</mi><mi>m</mi><mfenced close=")" open="("><mi>e</mi></mfenced><mspace width="3.0mm"/><mi>m</mi><mi>a</mi><mi>y</mi><mi>N</mi><mi>u</mi><mi>m</mi><mfenced close=")" open="("><mi>e</mi></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>:</mi><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>n</mi><mi>u</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi><mo>,</mo><mi>s</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>n</mi><mi>g</mi></mrow></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>e</mi><mo>.</mo><mi>o</mi><mi>p</mi><msup><mo>=</mo><mi>'</mi></msup><msup><mo>+</mo><mi>'</mi></msup><mspace width="3.0mm"/><mi>t</mi><mi>o</mi><mi>N</mi><mi>u</mi><mi>m</mi><mfenced close=")" open="("><mi>e</mi></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac></mtd></mtr><mtr><mtd><mfrac><mrow><mi>e</mi><mo>.</mo><mi>o</mi><mi>p</mi><msup><mo>≤</mo><mi>'</mi></msup><msup><mo>+</mo><mi>'</mi></msup></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac></mtd></mtr></mtable></math>
-<simpara>That is, if both operands are number, int, boolean, null, or even undefined, then the 'plus' is interpreted as
-mathematical addition and the result is a number. In other cases the 'plus' is interpreted as string concatenation and the result is a string. In case of union types, the result may be a union of number and string.</simpara>
-<simpara>Adding two integers (int) leads to a number, since the result may not be represented as an (JavaScript) int anymore.</simpara>
-<example>
-<title>Type of addition expression</title>
-<programlisting language="xtext" linenumbering="unnumbered">1+2; // number 3
-"1"+"2"; // string "12"
-"1"+2; // string "12"
-1+true; // number 2
-false+1; // number 1
-"1"+true; // string "1true"
-"1"+null; // string "1null"
-1+null; // number 1
-1+undefined; // number NaN
-"1"+undefined; // string "1undefined"</programlisting>
-</example>
-<simpara>Support new <literal>Symbol.toPrimitive</literal>.</simpara>
-</section>
-</section>
-<section xml:id="_bitwise-shift-expression">
-<title>Bitwise Shift Expression</title>
-<bridgehead xml:id="bitwise-shift-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<literallayout class="monospaced">Cf. +[+<<ECMA11a,ECMA11a(p.p.76f)>>+]+</literallayout>
-<programlisting language="xtext" linenumbering="unnumbered">ShiftExpression returns Expression: AdditiveExpression
- (=>({ShiftExpression.lhs=current} op=ShiftOperator rhs=AdditiveExpression))*
-;
-
-ShiftOperator returns ShiftOperator:
- '>' '>' '>'? // SHR, USHR
- | '<' '<' // SHL
- ;</programlisting>
-<bridgehead xml:id="bitwise-shift-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-112">
-<title>Bitwise Shift Expression Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-112" xreflabel="[Req-IDE-112]"/>
-<emphasis role="strong">Requirement: IDE-112:</emphasis>
-<link linkend="Req-IDE-112">Bitwise Shift Expression Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given bitwise shift expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> the following constraints must hold in N4JS mode:
-* The types of the operands can be any.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>BitwiseShiftExpression</mtext></mstyle><mi> </mi><mo>⊲</mo><mi> </mi><mstyle mathvariant="monospace"><mtext>Expression</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac></math>
-</requirement>
-<bridgehead xml:id="type-inference-11" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type returned by a bitwise shift expression is always <literal>number</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi> </mi><mrow><mo>(</mo><mrow><mstyle mathvariant="monospace"><mtext>Expression (’</mtext></mstyle><mo><</mo><mo><</mo><mstyle mathvariant="monospace"><mtext>’—’</mtext></mstyle><mo>></mo><mo>></mo><mstyle mathvariant="monospace"><mtext>’—’</mtext></mstyle><mo>></mo><mo>></mo><mo>></mo><mstyle mathvariant="monospace"><mtext>’)</mtext> <mtext>Expression</mtext></mstyle><mo>)</mo></mrow><mi>:</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mrow></mfrac><mtext>
-</mtext></math>
-<simpara>A non-numeric operand is interpreted as 0, except for <literal>true</literal> which is interpreted as <literal>1</literal>; or objects implementing the symbol <literal>toPrimitive</literal>.</simpara>
-</section>
-<section xml:id="_relational-expression">
-<title>Relational Expression</title>
-<bridgehead xml:id="relational-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.p.77ff)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">RelationalExpression returns Expression: ShiftExpression
- (=>({RelationalExpression.lhs=current} op=RelationalOperator) rhs=ShiftExpression)*;
-
-RelationalExpressionNoIn returns Expression: ShiftExpression
- (=>({RelationalExpression.lhs=current} op=RelationalOperatorNoIn) rhs=ShiftExpression)*;
-
-enum RelationalOperator:
- lt='<' | gt='>' | lte='<=' | gte='>=' | instanceof | in;
-RelationalOperatorNoIn returns RelationalOperator:
- '<' | '>' | '<=' | '>=' | 'instanceof';</programlisting>
-<bridgehead xml:id="relational-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-113">
-<title>Greater/Less (Equals) Operator Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-113" xreflabel="[Req-IDE-113]"/>
-<emphasis role="strong">Requirement: IDE-113:</emphasis>
-<link linkend="Req-IDE-113">Greater/Less (Equals) Operator Constraints</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For a given relational expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>∈</mo><mrow><mo>{</mo><mrow><mo><</mo><mo>,</mo><mo>></mo><mo>,</mo><mo><</mo><mo>=</mo><mo>,</mo><mo>></mo><mo>=</mo><mo>}</mo></mrow></mrow></math> in N4JS mode,
-the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The operands must have the same type and the type must be either a number, string, or boolean:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>T</mi><mspace width="3.0mm"/><mi>T</mi><mo>∈</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>number,string,boolean</mtext></mstyle></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mrow><mo>(</mo><mrow><mi>'</mi><msup><mo><</mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><mo><</mo><msup><mo>=</mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><msup><mo>></mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><mo>></mo><msup><mo>=</mo><mi>'</mi></msup><mo>)</mo></mrow><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>l</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>T</mi></mrow></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>O</mi><mspace width="3.0mm"/><mi>O</mi><mo>∉</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>number,string,boolean</mtext></mstyle></mfenced><mspace width="3.0mm"/><mi>T</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>number,string,boolean</mtext></mstyle></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mrow><mo>(</mo><mrow><mi>'</mi><msup><mo><</mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><mo><</mo><msup><mo>=</mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><msup><mo>></mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><mo>></mo><msup><mo>=</mo><mi>'</mi></msup><mo>)</mo></mrow><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>l</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>T</mi></mrow></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>T</mi><mspace width="3.0mm"/><mi>T</mi><mo>∈</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>number,string,boolean</mtext></mstyle></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mrow><mo>(</mo><mrow><mi>'</mi><msup><mo><</mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><mo><</mo><msup><mo>=</mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><msup><mo>></mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><mo>></mo><msup><mo>=</mo><mi>'</mi></msup><mo>)</mo></mrow><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>T</mi></mrow></mrow></mfrac></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>O</mi><mspace width="3.0mm"/><mi>O</mi><mo>∉</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>number,string,boolean</mtext></mstyle></mfenced><mspace width="3.0mm"/><mi>T</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>number,string,boolean</mtext></mstyle></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mrow><mo>(</mo><mrow><mi>'</mi><msup><mo><</mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><mo><</mo><msup><mo>=</mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><msup><mo>></mo><mi>'</mi></msup><msup><mo>|</mo><mi>'</mi></msup><mo>></mo><msup><mo>=</mo><mi>'</mi></msup><mo>)</mo></mrow><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>T</mi></mrow></mrow></mfrac></math></simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-114">
-<title>Instanceof Operator Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-114" xreflabel="[Req-IDE-114]"/>
-<emphasis role="strong">Requirement: IDE-114:</emphasis>
-<link linkend="Req-IDE-114">Instanceof Operator Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given relational expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>instanceof</mtext></mstyle></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The right operand of the instanceof operator must be a <literal>Function</literal> <footnote><simpara>Only <literal role="language-n4js">Function</literal> implements the ECMAScript specification property <literal role="language-n4js">hasInstance</literal>. Thus instanceof expressions are rewritten by the compiler for other types. Note that a reference to a class returns the constructor type, which actually is a function itself.</simpara></footnote></simpara>
-</listitem>
-</itemizedlist>
-<simpara>In other words,</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’instanceof’</mtext></mstyle><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle></mfenced></mrow></mfrac><mrow/></math>
-<simpara>is contained in the the first type rule, an object type reference <footnote><simpara>Includes interfaces, since an interface type reference is a subtype of object type reference: <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>Interface</mtext></mstyle></mfenced><mo><</mo><mi>:</mi><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>Object</mtext></mstyle></mfenced></math></simpara></footnote>
-or an enum type reference.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’instanceof’</mtext></mstyle><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>Function</mtext></mstyle></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’instanceof’</mtext></mstyle><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>Object</mtext></mstyle></mfenced></mrow></mfrac></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’instanceof’</mtext></mstyle><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>type</mtext></mstyle><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>N4Enum</mtext></mstyle></mfenced></mrow></mfrac></mtd></mtr></mtable></math>
-<simpara>The type of a definition site structural classifier <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> is not of type <literal>C</literal>.
-Thus, the <literal>instanceof</literal> operator cannot be used for structural types.
-Use-site structural typing is also not possible since <literal>~</literal> would be interpreted (by the parser) as a binary operator.</simpara>
-</requirement>
-<requirement xml:id="IDE-115">
-<title>Operator Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-115" xreflabel="[Req-IDE-115]"/>
-<emphasis role="strong">Requirement: IDE-115:</emphasis>
-<link linkend="Req-IDE-115">Operator Constraints</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For a given relational expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>in</mtext></mstyle></math>, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The right operand of the in operator must be an <literal>Object</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’in’</mtext></mstyle><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>Object</mtext></mstyle></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>In N4JS mode, the left operand is restricted to be of type <literal>string</literal> or <literal>number</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’in’</mtext></mstyle><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mo>⊲</mo><mi> </mi><mi>l</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>string,number</mtext></mstyle></mfenced></mrow></mfrac></math>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>A special feature of N4JS is support for interface type references in combination with the <literal>instance of</literal> operator.
-The compiler rewrites the code to make this work.</simpara>
-<example>
-<title><literal>instanceof</literal> with Interface</title>
-<simpara>The following example demonstrates the use of the operator with an interface.
-This is, of course, not working in pure ECMAScript.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">interface I {}
-
-class A implements I {}
-class B extends A {}
-class C {}
-
-function f(name: string, p: any) {
- if (p instanceof I) {
- console.log(name + " is instance of I");
- }
-}
-
-f("A", new A())
-f("B", new B())
-f("C", new C())</programlisting>
-<simpara>This will print out</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">A is instance of I
-B is instance of I</programlisting>
-</example>
-<bridgehead xml:id="type-inference-12" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type of a relational expression always is <literal>boolean</literal>;</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mfenced close=")" open="("><mrow><mstyle mathvariant="monospace"><mtext>’¡’</mtext></mstyle><mo>|</mo><mstyle mathvariant="monospace"><mtext>’¡=’</mtext></mstyle><mo>|</mo><mstyle mathvariant="monospace"><mtext>’¿’</mtext></mstyle><mo>|</mo><mstyle mathvariant="monospace"><mtext>’¿=’</mtext></mstyle><mo>|</mo><mstyle mathvariant="monospace"><mtext>’instanceof’</mtext></mstyle><mo>|</mo><mstyle mathvariant="monospace"><mtext>’in’</mtext></mstyle></mrow></mfenced><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>boolean</mtext></mstyle></mrow></mfrac></math>
-</section>
-<section xml:id="_equality-expression">
-<title>Equality Expression</title>
-<bridgehead xml:id="equality-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.p.80ff)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">EqualityExpression returns Expression: RelationalExpression
- (=>({EqualityExpression.lhs=current} op=EqualityOperator) rhs=RelationalExpression)*;
-
-EqualityExpressionNoIn returns Expression: RelationalExpressionNoIn
- (=>({EqualityExpression.lhs=current} op=EqualityOperator) rhs=RelationalExpressionNoIn)*;
-
-
-enum EqualityOperator: same='===' | nsame='!==' | eq='==' | neq='!=';</programlisting>
-<bridgehead xml:id="equality-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>There are no hard constraints defined for equality expressions.</simpara>
-<simpara>In N4JSmode, a warning is created if for a given expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>l</mi><mi>h</mi><mi>s</mi><mstyle mathvariant="monospace"><mtext>(’===’—’!==’)</mtext></mstyle><mi>r</mi><mi>h</mi><mi>s</mi></math>, neither <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mo><</mo><mi>:</mi><mi>r</mi><mi>h</mi><mi>s</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi></math> nor <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>⊢</mo><mi>r</mi><mi>h</mi><mi>s</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi><mo><</mo><mi>:</mi><mi>l</mi><mi>h</mi><mi>s</mi><mo>.</mo><mi>u</mi><mi>p</mi><mi>p</mi><mi>e</mi><mi>r</mi></math>
-and no interface or composed type is involved as the result is constant in these cases.</simpara>
-<simpara>Note that a warning is only created if the upper bounds do not match the described constraints.
-This is necessary for wildcards. For example in</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">// with
-class A{} class B extends A{}
-function isFirst(ar: Array<? extends A>, b: B): boolean {
- return b === ar[0]
-}</programlisting>
-<simpara>the type of array elements is <literal>? extends A</literal>.<?asciidoc-br?>
-Neither <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>? extends A</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle></math> nor <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>B</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>? extends A</mtext></mstyle></math> is true.
-This is why the upper bounds are to be used.</simpara>
-<bridgehead xml:id="type-inference-13" renderas="sect4">Type Inference</bridgehead>
-<simpara>The inferred type of an equality expression always is <literal>boolean</literal>.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mi> </mi><mfenced close=")" open="("><mrow><mstyle mathvariant="monospace"><mtext>’==’</mtext></mstyle><mo>|</mo><mstyle mathvariant="monospace"><mtext>’!=’</mtext></mstyle><mo>|</mo><mstyle mathvariant="monospace"><mtext>’===’</mtext></mstyle><mo>|</mo><mstyle mathvariant="monospace"><mtext>’!==’</mtext></mstyle></mrow></mfenced><mi> </mi><mi>r</mi><mi>h</mi><mi>s</mi><mi> </mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>boolean</mtext></mstyle></mrow></mfrac></math>
-</section>
-<section xml:id="_binary-bitwise-expression">
-<title>Binary Bitwise Expression</title>
-<bridgehead xml:id="binary-bitwise-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.p.82ff)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">BitwiseANDExpression returns Expression: EqualityExpression
- (=> ({BitwiseANDExpression.lhs=current} '&') rhs=EqualityExpression)*;
-
-BitwiseANDExpressionNoIn returns Expression: EqualityExpressionNoIn
- (=> ({BitwiseANDExpression.lhs=current} '&') rhs=EqualityExpressionNoIn)*;
-
-BitwiseXORExpression returns Expression: BitwiseANDExpression
- (=> ({BitwiseXORExpression.lhs=current} '^') rhs=BitwiseANDExpression)*;
-
-BitwiseXORExpressionNoIn returns Expression: BitwiseANDExpressionNoIn
- (=> ({BitwiseXORExpression.lhs=current} '^') rhs=BitwiseANDExpressionNoIn)*;
-
-BitwiseORExpression returns Expression: BitwiseXORExpression
- (=> ({BitwiseORExpression.lhs=current} '|') rhs=BitwiseXORExpression)*;
-
-BitwiseORExpressionNoIn returns Expression: BitwiseXORExpressionNoIn
- (=> ({BitwiseORExpression.lhs=current} '|') rhs=BitwiseXORExpressionNoIn)*;</programlisting>
-<bridgehead xml:id="binary-bitwise-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-116">
-<title>Bitwise Bitwise Expression Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-116" xreflabel="[Req-IDE-116]"/>
-<emphasis role="strong">Requirement: IDE-116:</emphasis>
-<link linkend="Req-IDE-116">Bitwise Bitwise Expression Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given bitwise bitwise expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> the following constraints must hold in N4JS mode:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The types of the operands must be both number.</simpara>
-</listitem>
-</itemizedlist>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>BitwiseBitwiseExpression</mtext></mstyle><mi> </mi><mo>⊲</mo><mi> </mi><mstyle mathvariant="monospace"><mtext>Expression</mtext></mstyle><mi>:</mi><mstyle mathvariant="monospace"><mtext>number</mtext></mstyle></mrow></mfrac></math>
-</requirement>
-<bridgehead xml:id="type-inference-14" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type returned by a binary bitwise expression is always <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mi>u</mi><mi>m</mi><mi>b</mi><mi>e</mi><mi>r</mi></math>:</simpara>
-
-</section>
-<section xml:id="_binary-logical-expression">
-<title>Binary Logical Expression</title>
-<bridgehead xml:id="binary-logical-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<programlisting language="xtext" linenumbering="unnumbered">LogicalANDExpression returns Expression: BitwiseORExpression
- (=> ({LogicalANDExpression.lhs=current} '&&') rhs=BitwiseORExpression)*;
-LogicalANDExpressionNoIn returns Expression: BitwiseORExpressionNoIn
- (=> ({LogicalANDExpression.lhs=current} '&&') rhs=BitwiseORExpressionNoIn)*;
-
-LogicalORExpression returns Expression: LogicalANDExpression
- (=> ({LogicalORExpression.lhs=current} '||') rhs=LogicalANDExpression)*;
-LogicalORExpressionNoIn returns Expression: LogicalANDExpressionNoIn
- (=> ({LogicalORExpression.lhs=current} '||') rhs=LogicalANDExpressionNoIn)*;</programlisting>
-<bridgehead xml:id="binary-logical-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-117">
-<title>Binary Logical Expression Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-117" xreflabel="[Req-IDE-117]"/>
-<emphasis role="strong">Requirement: IDE-117:</emphasis>
-<link linkend="Req-IDE-117">Binary Logical Expression Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given binary logical expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>l</mi><mi>h</mi><mi>s</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>L</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>r</mi><mi>h</mi><mi>s</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>R</mi></math> the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>In N4JS mode <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>L</mi></math> must not be <literal>undefined</literal> or <literal>null</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<bridgehead xml:id="type-inference-15" renderas="sect4">Type Inference</bridgehead>
-<simpara>The evaluation relies on ECMAScript’s abstract operation <literal>ToBoolean</literal> [<link linkend="ECMA11a">ECMA11a(p.p.43)</link>].
-A short-circuit evaluation strategy is used so that depending on the types of the operands, different result types may be inferred.
-In particular, the inferred type usually is not <literal>boolean</literal> ((cf. [<link linkend="ECMA11a">ECMA11a(p.S11.11., p.p.83ff)</link>] ).
-The type inference does not take this short-circuit evaluation strategy into account, as it will affect the result in case one of the types is <literal>null</literal>
-either or <literal>undefined</literal>, which is not allowed in N4JS mode.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi><mstyle mathvariant="monospace"><mtext>’</mtext></mstyle><mi>&</mi><mi>&</mi><mstyle mathvariant="monospace"><mtext>’—’——’</mtext></mstyle><mi>r</mi><mi>h</mi><mi>s</mi><mi>:</mi><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>h</mi><mi>s</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>r</mi><mi>h</mi><mi>s</mi></mrow></mfenced></mrow></mfrac></math>
-</section>
-<section xml:id="_conditional-expression">
-<title>Conditional Expression</title>
-<bridgehead xml:id="conditional-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S11.12, p.p.84)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ConditionalExpression returns Expression: LogicalORExpression
- (=> ({ConditionalExpression.expression=current} '?') trueExpression=AssignmentExpression ':' falseExpression=AssignmentExpression)?;
-
-ConditionalExpressionNoIn returns Expression: LogicalORExpressionNoIn
- (=> ({ConditionalExpression.expression=current} '?') trueExpression=AssignmentExpression ':' falseExpression=AssignmentExpressionNoIn)?;</programlisting>
-<bridgehead xml:id="conditional-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-118">
-<title>Conditional Expression Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-118" xreflabel="[Req-IDE-118]"/>
-<emphasis role="strong">Requirement: IDE-118:</emphasis>
-<link linkend="Req-IDE-118">Conditional Expression Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given conditional expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> with</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>C</mi><mo>,</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>T</mi><mo>,</mo></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>f</mi><mi>a</mi><mi>l</mi><mi>s</mi><mi>e</mi><mo>-</mo><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>:</mi><mi>F</mi></math></simpara>
-<simpara>the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>A warning will be issued in N4JSmode if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></math> evaluates to a constant value.
-That is to say<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>∈</mo><mfenced close="}" open="{"><mrow><mi>f</mi><mi>a</mi><mi>l</mi><mi>s</mi><mi>e</mi></mrow><mrow><mi>t</mi><mi>r</mi><mi>u</mi><mi>e</mi></mrow><mrow><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi></mrow><mrow><mi>u</mi><mi>n</mi><mi>d</mi><mi>e</mi><mi>f</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi></mrow></mfenced></math> or
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>∈</mo><mfenced close="}" open="{"><mstyle mathvariant="monospace"><mtext>void</mtext></mstyle><mstyle mathvariant="monospace"><mtext>undefined</mtext></mstyle></mfenced></math>.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>There are no specific constraints defined for the condition.
-The ECMAScript operation <literal>ToBoolean</literal> [<link linkend="ECMA11a">ECMA11a(p.S9.2, p.p.43)</link>] is used to convert any type to boolean.</simpara>
-</requirement>
-<bridgehead xml:id="type-inference-16" renderas="sect4">Type Inference</bridgehead>
-<simpara>The inferred type of a conditional expression is the union of the true and false expression (cf. [<link linkend="ECMA11a">ECMA11a(p.S11.12, p.p.84)</link>] ():</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>T</mi><mo>=</mo><mi>u</mi><mi>n</mi><mi>i</mi><mi>o</mi><mi>n</mi><mfenced close="}" open="{"><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>t</mi><mo>,</mo><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>f</mi></mrow></mfenced></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>d</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’?’</mtext></mstyle><mi>e</mi><mi>t</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’:’</mtext></mstyle><mi>e</mi><mi>f</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-<example>
-<title>Type of Conditional Expressions</title>
-<simpara>Given the following declarations:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A{} class B extends A{}
-class C{} class D extends A{}
-class G<T> { field: T; }
-
-var ga: G<A>, gb: G<B>;
- a: A, b: B, c: C, d: D;
-var boolean cond;</programlisting>
-<simpara>Then the type of the following conditional expression is inferred as noted in the comments:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">cond ? a : a; // A
-cond ? a : b; // union{A,B}
-cond ? a : c; // union{A,C}
-cond ? b : d; // union{B,D}
-cond ? (cond ? a : b) : (cond ? c : d); // union{A,B,C,D}
-cond ? (cond ? a : b) : (cond ? b : d); // union{A,B,D}
-cond ? ga : gb; // union{G<A>,G<B>}</programlisting>
-</example>
-</section>
-<section xml:id="_assignment-expression">
-<title>Assignment Expression</title>
-<bridgehead xml:id="assignment-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<programlisting language="xtext" linenumbering="unnumbered">AssignmentExpression <In, Yield>:
- lhs=Expression op=AssignmentOperator rhs=AssignmentExpression<In,Yield>
-;
-AssignmentOperator:
- '='
- | '*=' | '/=' | '%=' | '+=' | '-='
- | '<<=' | '>>=' | '>>>='
- | '&=' | '^=' | '|='
-;</programlisting>
-<bridgehead xml:id="assignment-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-119">
-<title>Simple Assignment</title>
-<simpara>
-<anchor xml:id="Req-IDE-119" xreflabel="[Req-IDE-119]"/>
-<emphasis role="strong">Requirement: IDE-119:</emphasis>
-<link linkend="Req-IDE-119">Simple Assignment</link> (ver. 1)</simpara>
- <simpara>
-
-For a given assignment <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi></math> with</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mo>.</mo><mi>o</mi><mi>p</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>’=’</mtext></mstyle></math></simpara>
-<simpara>the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mo>.</mo><mi>l</mi><mi>h</mi><mi>s</mi></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mo>.</mo><mi>r</mi><mi>h</mi><mi>s</mi></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math></simpara>
-<simpara>In the following inference rule and the constraint, ’@’ is to be replaced with the right part of one of the assignment operators listed above, that is,</simpara>
-
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-120">
-<title>Compound Assignment</title>
-<simpara>
-<anchor xml:id="Req-IDE-120" xreflabel="[Req-IDE-120]"/>
-<emphasis role="strong">Requirement: IDE-120:</emphasis>
-<link linkend="Req-IDE-120">Compound Assignment</link> (ver. 1)</simpara>
- <simpara>
-
-For a given assignment <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mi> </mi><mi>o</mi><mi>p</mi><mi> </mi><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></math>, with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>o</mi><mi>p</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>’@=’</mtext></mstyle></math> but not <literal>+=</literal>, both, left and right must be subtypes of <literal>number</literal>.<?asciidoc-br?>
-For operator <literal>+=</literal>,</simpara>
-<itemizedlist>
-<listitem>
-<simpara>if the left-hand side is a <literal>number</literal>, then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’+’</mtext></mstyle><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></math> must return a number as well.
-The right-hand side must, in fact, be a <literal>number</literal> (and not a <literal>boolean</literal>) here in order to avoid unexpected results.</simpara>
-</listitem>
-<listitem>
-<simpara>if the left-hand side is a <literal>string</literal>, then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mstyle mathvariant="monospace"><mtext>’+’</mtext></mstyle><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi></math> must return a string as well.
-That means that the right-hand side can be of <literal>any</literal> type.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The expected type for the left-hand side is <literal>union{number,string}</literal>.</simpara>
-<simpara>The basic idea behind these constraints is that the type of the left-hand side is not to be changed by the compound assignment.</simpara>
-</requirement>
-<requirement xml:id="IDE-121">
-<title>Write Acccess</title>
-<simpara>
-<anchor xml:id="Req-IDE-121" xreflabel="[Req-IDE-121]"/>
-<emphasis role="strong">Requirement: IDE-121:</emphasis>
-<link linkend="Req-IDE-121">Write Acccess</link> (ver. 1)</simpara>
- <simpara>
-
-For a given assignment expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi></math>, the left-hand side must be writeable or a final data field and the assignment must be in the constructor.
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi></math> be the bound variable (or field) with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mrow><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow><mi>v</mi></mfenced></math></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mi>v</mi><mo>.</mo><mi>w</mi><mi>r</mi><mi>i</mi><mi>t</mi><mi>e</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi><mo>∨</mo><mi>v</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>∧</mo><mspace width="3.0mm"/><mspace width="2.0em"/><mi>v</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mspace width="2.0em"/><mo>∧</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>=</mo><mi>v</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mspace width="2.0em"/><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><mrow><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>PropertyAccess</mtext></mstyle></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mspace width="4.0em"/><mo>∧</mo><mi>a</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>g</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>"this"</mtext></mstyle></mtd></mtr></mtable></math>
-<simpara>The value of writeable is true for setters and usually for variables and data fields.
-Assignability of variables and data fields can be restricted via <literal>const</literal> or the <literal>@Final</literal> annotation.
-See <xref linkend="_assignment-modifiers"/>(data fields) and <xref linkend="_const"/> (const variables) for details.</simpara>
-<simpara>Also see <xref linkend="Req-IDE-93"/> for read access constraint.</simpara>
-<simpara>The left-hand side of an assignment expression may be an array or object literal and the assignment expression is then treated as a destructuring assignment.
-See <xref linkend="_array-and-object-destructuring"/> for details.</simpara>
-</requirement>
-<bridgehead xml:id="type-inference-17" renderas="sect4">Type Inference</bridgehead>
-<simpara>Similarly to [<link linkend="ECMA11a">ECMA11a(p.S11.1, p.p.84ff)</link>], we define type inference for simple assignment (<literal>=</literal>) and compound assignment (<literal>op=</literal>) individually.</simpara>
-<simpara>The type of the assignment is simply the type of the right-hand side:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi><mi>:</mi><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’=’</mtext></mstyle><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-<simpara>Compound assignments are reduced to the former by splitting an operator <literal>@=</literal>, in which <literal>@</literal> is a simple operator,
-into a simple operator expression with operator <literal>@</literal> and a simple assignment <literal>=</literal>.
-Since the type of the latter is the right-hand side, we can define:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’@’</mtext></mstyle><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi><mi>:</mi><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>l</mi><mi>e</mi><mi>f</mi><mi>t</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>’@=’</mtext></mstyle><mi>r</mi><mi>i</mi><mi>g</mi><mi>h</mi><mi>t</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-</section>
-<section xml:id="_comma-expression">
-<title>Comma Expression</title>
-<bridgehead xml:id="comma-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S11.14, p.p.85)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">CommaExpression <In, Yield>:
- exprs+=AssignmentExpression<In,Yield> ',' exprs+=AssignmentExpression<In,Yield>
- (',' exprs+=AssignmentExpression<In,Yield>)*
-;</programlisting>
-<bridgehead xml:id="comma-expression-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>All expressions will be evaluated even though only the value of the last expression will be the result.</simpara>
-<example>
-<title>Comma Expression</title>
-<simpara>Assignment expressions preceed comma expressions:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var b: boolean;
-b = (12, 34, true); // ok, b=true
-b = 12, 34, true ; // error, b=12 is invalid</programlisting>
-</example>
-<bridgehead xml:id="type-inference-18" renderas="sect4">Type Inference</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S11.14, p.p.85)</link>]</simpara>
-<simpara>The type of a comma expression <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi></math> is inferred to the last expression:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>n</mi><mo>=</mo><mo>|</mo><mi>c</mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>s</mi><mo>|</mo><mo>,</mo><mi>Γ</mi><mo>⊢</mo><mi>c</mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><msub><mi>s</mi><mi>n</mi></msub><mi>:</mi><mi>T</mi></mrow><mrow><mi>Γ</mi><mo>⊢</mo><mi>c</mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-</section>
-</section>
-<section xml:id="_ecmascript-6-expressions" role="language-n4js">
-<title>ECMAScript 6 Expressions</title>
-<section xml:id="_the-super-keyword">
-<title>The super Keyword</title>
-<programlisting language="n4js" linenumbering="unnumbered">SuperLiteral: {SuperLiteral} 'super';</programlisting>
-<simpara>Apart from the use of keyword <literal>super</literal> in wildcards of type expressions (cf. <xref linkend="_type-expressions"/>),
-there are two use cases for keyword <literal>super</literal>: super member access and super constructor calls.</simpara>
-<example>
-<title>Super Keyword</title>
-<simpara>Two use cases for keyword super:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class B extends A {
- constructor() {
- // super call
- super();
- }
- @Override
- m();: void {
- // super member access
- super.m();
- }
-}</programlisting>
-</example>
-<bridgehead xml:id="super-keyword-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara><literal>super</literal> can be used to access the supertype’s constructor, methods, getters and setters.
-The supertype is defined lexically, which is different from how <literal>this</literal> works.<footnote><simpara>See [<link linkend="ECMA15a">ECMA15a</link>], Chapter 12.3.5 "The Super Keyword"; note the use of <literal>HomeObject</literal> instead of <literal>thisValue</literal>; also see this blog - <link xl:href="http://www.2ality.com/2011/11/super-references.html">http://www.2ality.com/2011/11/super-references.html</link>.</simpara></footnote></simpara>
-<simpara>Note that in [<link linkend="ECMA15a">ECMA15a</link>] Chapter 12.3.5 <literal>The Super Keyword</literal>, <literal>super</literal> is defined as a keyword but the syntax and semantics are defined in conjunction of member access.</simpara>
-<requirement xml:id="IDE-122">
-<title>Type of Super is Always Nominal</title>
-<simpara>
-<anchor xml:id="Req-IDE-122" xreflabel="[Req-IDE-122]"/>
-<emphasis role="strong">Requirement: IDE-122:</emphasis>
-<link linkend="Req-IDE-122">Type of Super is Always Nominal</link> (ver. 1)</simpara>
- <simpara>
-
-The type referenced with the super literal is always nominal.
-This is a consequence of references to types in extend clauses to be nominal.</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>super</mtext></mstyle><mi>:</mi><mi>T</mi><mo>∧</mo><mi>T</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>t</mi><mi>e</mi><mi>g</mi><mi>y</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>nominal</mtext></mstyle></math></simpara>
-</requirement>
-<requirement xml:id="IDE-123">
-<title>Access Super Constructor with Super Literal</title>
-<simpara>
-<anchor xml:id="Req-IDE-123" xreflabel="[Req-IDE-123]"/>
-<emphasis role="strong">Requirement: IDE-123:</emphasis>
-<link linkend="Req-IDE-123">Access Super Constructor with Super Literal</link> (ver. 1)</simpara>
- <simpara>
-
-If the super literal <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi></math> is used to access the super constructor of a class, all of the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The super constructor access must be a call expression:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>μ</mi><mfenced close=")" open="("><mrow><mi>c</mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>CallExpression</mtext></mstyle><mo>∧</mo><mi>c</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>=</mo><mi>c</mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi></math>
-</listitem>
-<listitem>
-<simpara>The super constructor call must be the expression of an expression statement <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi></math>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi><mo>=</mo><mi>c</mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>∧</mo><mi>μ</mi><mfenced close=")" open="("><mrow><mi>c</mi><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>ExpressionStatement</mtext></mstyle></math>
-</listitem>
-<listitem>
-<simpara>The containing statement <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>t</mi><mi>m</mi><mi>t</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi></math> must be directly contained in a constructor body:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mi>μ</mi><mfenced close=")" open="("><mrow><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Constructor</mtext></mstyle><mo>)</mo></mrow></math>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="3.0mm"/><mo>∧</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>=</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>b</mi><mi>o</mi><mi>d</mi><mi>y</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>There must be no access to and not return statement before the containing statement <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi></math>.</simpara>
-<simpara>Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>i</mi></math> be the index of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi></math> in the constructor body:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>m</mi><mi>t</mi><msub><mi>s</mi><mrow><mi>s</mi><mi>i</mi></mrow></msub><mo>=</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi></math>
-<simpara>Then, the following constraint must hold: <footnote><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><msup><mo>∈</mo><mo>*</mo></msup><mi>c</mi></math> is the transitive version of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mo>∈</mo><mi>c</mi></math>, that is, it <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi></math> directly or indirectly contained in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi></math>.</simpara></footnote></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mspace width="3.0mm"/><mo>∀</mo><mi>i</mi><mo><</mo><mi>s</mi><mi>i</mi><mi>:</mi><mo>∄</mo><mi>e</mi><mi>l</mi><mi>e</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><msup><mo>∈</mo><mo>*</mo></msup><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>m</mi><mi>t</mi><msub><mi>s</mi><mi>i</mi></msub><mi>:</mi><mtext>
-</mtext><mspace width="3.0mm"/><mspace width="3.0em"/><mi>μ</mi><mfenced close=")" open="("><mi>i</mi></mfenced><mo>∈</mo><mstyle mathvariant="monospace"><mtext>ThisLiteral, ReturnStatement</mtext></mstyle></math>
-</listitem>
-</orderedlist>
-<simpara>Further constraints with regard to super constructor calls are described in <xref linkend="_constructor-and-classifier-type"/>.</simpara>
-</requirement>
-<requirement xml:id="IDE-124">
-<title>Access Super Member with Super Literal</title>
-<simpara>
-<anchor xml:id="Req-IDE-124" xreflabel="[Req-IDE-124]"/>
-<emphasis role="strong">Requirement: IDE-124:</emphasis>
-<link linkend="Req-IDE-124">Access Super Member with Super Literal</link> (ver. 1)</simpara>
- <simpara>
-
-If the super literal <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi></math> is used to access a member of the super class, all of the following constraints must hold, with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mo>=</mo><mi>s</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>r</mi></math></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The super literal must be the receiver of a method call (cf. remarks below):</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>c</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>CallExpression</mtext></mstyle></mtd></mtr><mtr><mtd><mo>∧</mo><mspace width="3.0mm"/><mi>c</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>PropertyAccessExpression</mtext></mstyle></mtd></mtr><mtr><mtd><mo>∧</mo><mspace width="3.0mm"/><mi>c</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>=</mo><mi>s</mi></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara>The super literal is used in a method or field accessor of a class:</simpara>
-</listitem>
-</orderedlist>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mrow><mi>s</mi><mo>.</mo><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi></mrow></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle></math>
-3. The super literal must not be used in a nested function expression:</simpara>
-<simpara>+
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>μ</mi><mfenced close=")" open="("><mrow><mi>s</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi></mrow></mfenced><mo>=</mo><mi>s</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>M</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>O</mi><mi>r</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>A</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>o</mi><mi>r</mi></math>
-4. If the return type of the method access via super is this, the actually bound this type will be the type of the calling class (and not of the class defining the method).</simpara>
-<simpara>+</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mi>s</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>C</mi><mi>l</mi><mi>a</mi><mi>s</mi><mi>s</mi><mo>=</mo><mi>T</mi><mspace width="3.0mm"/><mi>μ</mi><mfenced close=")" open="("><mi>m</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Method</mtext></mstyle><mspace width="3.0mm"/><mi>m</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>this</mtext></mstyle></mrow><mrow><mstyle mathvariant="monospace"><mtext>function():T</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>s</mi><mo>.</mo><mi>m</mi></mrow></mfrac></math>
-</requirement>
-<requirement xml:id="IDE-125">
-<title>Super Literal Usage</title>
-<simpara>
-<anchor xml:id="Req-IDE-125" xreflabel="[Req-IDE-125]"/>
-<emphasis role="strong">Requirement: IDE-125:</emphasis>
-<link linkend="Req-IDE-125">Super Literal Usage</link> (ver. 1)</simpara>
- <simpara>
-
-For super literals, either <xref linkend="Req-IDE-123"/> or <xref linkend="Req-IDE-124"/> must hold, no other usage
-is allowed.</simpara>
-<simpara>Consequences:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Since fields cannot be overridden (except for changing the access modifier), it is not possible nor allowed to access a field via <literal>super</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Super literals must not be used with index access (e.g., <literal>super["foo"]</literal>)</simpara>
-</listitem>
-<listitem>
-<simpara>It is not possible to chain super keywords. That is, it is not possible to call <literal>super.super.m()</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>It is not allowed to use the super literal in interfaces or non-methods/accessors.</simpara>
-</listitem>
-<listitem>
-<simpara>Super cannot be used to call an overridden method of an implemented method from the overriding method in the implementing class.</simpara>
-</listitem>
-<listitem>
-<simpara>In order to be able to access a super method of a method <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math> of a class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math>, exactly one non-abstract super method <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math> in a super class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> must exist.
-This is assured by the standard rules for binding identifiers.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>If super is used to access a super member, the receiver type is not changed.
-This is important in particular for static methods as demonstrated in the following example:</simpara>
-<example>
-<title>Super Call in Static Methods</title>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- static foo(): void { console.log("A") }
- static bar(): void {
- this.foo();
- }
-}
-
-class B extends A {
-
- @Override
- static foo(): void { console.log("B") }
- @Override
- static bar(): void {
- A.bar(); <co xml:id="CO5-1"/>
- super.bar(); <co xml:id="CO5-2"/>
- }
-}
-
-B.bar();</programlisting>
-</example>
-<calloutlist>
-<callout arearefs="CO5-1">
-<para>The receiver (which is similar to the this-binding in ECMAScript) is changed to <literal>A</literal>.</para>
-</callout>
-<callout arearefs="CO5-2">
-<para>Using super, the receiver is preserved, i.e. <literal>B</literal>.</para>
-</callout>
-</calloutlist>
-</requirement>
-</section>
-</section>
-<section xml:id="_ecmascript-7-expressions" role="language-n4js">
-<title>ECMAScript 7 Expressions</title>
-<section xml:id="_await-expression">
-<title>Await Expression</title>
-<simpara>In N4JS, <literal>await</literal> is implemented as a unary operator with the same precedence as <literal>yield</literal> in ECMAScript 6.</simpara>
-<simpara>Constraints governing the use of <literal>await</literal> are given together with those for <literal>async</literal> in <xref linkend="_asynchronous-functions"/>.</simpara>
-</section>
-</section>
-<section xml:id="_n4js-specific-expressions" role="language-n4js">
-<title>N4JS Specific Expressions</title>
-<section xml:id="_class-expression">
-<title>Class Expression</title>
-<simpara>A class expression in N4JS is similar to a class expression in ECMAScript 6 [<link linkend="ECMA15a">ECMA15a(p.14.5)</link>].</simpara>
-<note>
-<simpara>Class expressions are not part of version 0.3</simpara>
-</note>
-<bridgehead xml:id="class-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>See <xref linkend="_classes"/>.</simpara>
-<bridgehead xml:id="class-expression-semantics-type-inference" renderas="sect4">Semantics and Type Inference</bridgehead>
-<simpara>The inferred type of a class expression simply is the class type as described in <xref linkend="_constructor-and-classifier-type"/>.</simpara>
-</section>
-<section xml:id="_cast-as-expression">
-<title>Cast (As) Expression</title>
-<bridgehead xml:id="cast-as-expression-syntax" renderas="sect4">Syntax</bridgehead>
-<programlisting language="xtext" linenumbering="unnumbered">CastExpression <Yield> returns Expression: expression=Expression 'as' targetTypeRef=TypeRefForCast;
-
-TypeRefForCast returns StaticBaseTypeRef:
- ParameterizedTypeRef
- | ThisTypeRef
- | ConstructorTypeRef
- | ClassifierTypeRef
- | FunctionTypeExpression
- | UnionTypeExpression
- | IntersectionTypeExpression</programlisting>
-<section xml:id="cast-as-expression-semantics-type-inference">
-<title>Semantics and Type Inference</title>
-<simpara>The inferred type of the type cast expression is the target type:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi> </mi><mstyle mathvariant="monospace"><mtext>"as"</mtext></mstyle><mi> </mi><mi>T</mi><mi>:</mi><mi>T</mi></mrow></mfrac></math>
-<simpara>The type cast returns the expression without further modifications.
-Type casts are simply removed during compilation so there will be no exceptions thrown at the cast until later when accessing properties which may not be present in case of a failed cast.</simpara>
-<simpara>An error is issued if the cast is either unnecessary or cannot succeed.
-See further details in <xref linkend="_type-cast"/>.</simpara>
-</section>
-</section>
-<section xml:id="Import_Calls">
-<title>Import Calls</title>
-<simpara>Import calls as specified by the corresponding <link xl:href="https://github.com/tc39/proposal-dynamic-import">ECMA TC39 proposal</link> are
-available in N4JS. Such an import call has the form</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import(moduleSpecifier)</programlisting>
-<simpara>and may appear in the source code wherever an expression may appear. It’s argument need not be a string literal, as is
-the case with module specifiers of ordinary imports; instead, any expression that evaluates to a string at runtime is
-accepted. Hence, it can be used to import from a target module that is not yet known at compile time.</simpara>
-<simpara>A note on terminology: import calls covered in this section are sometimes referred to as "dynamic import". In N4JS
-that term is already used for imports of the form <literal>import * as N+ from "…​"</literal>, i.e. compile-time imports that do not
-require type information of the module imported from, see <xref linkend="Dynamic_Imports"/>, and stems from the term "dynamic type"
-(see <xref linkend="Type_Modifiers_Dynamic"/>). To avoid confusion, we will usually avoid referring to import calls as a "dynamic
-import".</simpara>
-</section>
-</section>
-<section xml:id="compile-time-expressions" role="language-n4js">
-<title>Compile-Time Expressions</title>
-<simpara>A compile-time expression is an expression that can be fully evaluated at compile time. Not all expressions introduced
-in the previous sections qualify as compile-time expressions. Some forms of expressions always qualify (e.g. a string
-literal is always a compile-time expression), some never (e.g. call expressions), and for some expressions the operands
-must be of a certain value. The latter applies, for example, to divison: <literal>5 / 0</literal> is a valid ECMAScript expression (evaluating
-to <literal>NaN</literal>) but is not a compile-time expression. So it’s the actual compile-time value of the divisor that makes the difference,
-here. In any case, if an expression has operands, it is a compile-time expression only if all operands are compile-time expressions.</simpara>
-<simpara>The value a compile-time expression evaluates to at compile-time is called <emphasis>compile-time value</emphasis>. So, an expression has a compile-time
-value if and only if it is a compile-time expression.</simpara>
-<definition>
-<title>Compile-Time Expression</title>
-<simpara>
-<anchor xml:id="compile-time_expression" xreflabel="[compile-time_expression]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="compile-time_expression">Compile-Time Expression</link></simpara>
-<simpara>
-
-The following expressions are called compile-time expressions:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>undefined</literal> (but not <literal>NaN</literal> or <literal>Infinity</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>the <literal>null</literal> literal.</simpara>
-</listitem>
-<listitem>
-<simpara>all boolean, numeric, and string literals.</simpara>
-</listitem>
-<listitem>
-<simpara>template string literals, iff all embedded expressions are compile-time expressions.</simpara>
-</listitem>
-<listitem>
-<simpara>a parenthesis expression, iff its nested expression is a compile-time expression.</simpara>
-</listitem>
-<listitem>
-<simpara>unary expressions in case of the following operators:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>!</literal> iff the operand is a compile-time expression and evaluates to a boolean value.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>+</literal> iff the operand is a compile-time expression and evaluates to a numeric value.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>-</literal> iff the operand is a compile-time expression and evaluates to a numeric value.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>void</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>binary expressions in case of the following operators:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>+</literal> iff both operands are compile-time expressions and</simpara>
-<itemizedlist>
-<listitem>
-<simpara>both evaluate to numeric values, or</simpara>
-</listitem>
-<listitem>
-<simpara>at least one evaluates to a string value.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara><literal>-</literal>, <literal>*</literal> iff both operands are compile-time expressions and evaluate to numeric values.</simpara>
-</listitem>
-<listitem>
-<simpara><literal>/</literal>, <literal>%</literal> iff both operands are compile-time expressions and evaluate to numeric values and the right-hand operand is non-zero (i.e. division by zero is disallowed in compile-time expression, because <literal>NaN</literal> is not a supported compile-time value).</simpara>
-</listitem>
-<listitem>
-<simpara><literal>&&</literal>, <literal>||</literal> iff both operands are compile-time expressions and evaluate to boolean values.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>a tertiary conditional expression, iff the first operand is a compile-time expression evaluating to a boolean value B and</simpara>
-<itemizedlist>
-<listitem>
-<simpara>in case B is true, the second operand is a compile-time expression.</simpara>
-</listitem>
-<listitem>
-<simpara>in case B is false, the third operand is a compile-time expression.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>an identifier reference to a const variable, iff its initializer expression is a compile-time expression.</simpara>
-</listitem>
-<listitem>
-<simpara>a property access expression, iff it is direct (see <xref linkend="property-access-direct"/>) and refers to</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a built-in symbol, e.g. <literal>Symbol.iterator</literal>,</simpara>
-</listitem>
-<listitem>
-<simpara>a literal of a <literal>@StringBased</literal> enum, or</simpara>
-</listitem>
-<listitem>
-<simpara>a const field with a compile-time initializer expression.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-<simpara>In all other cases, the expression is not a compile-time expression.</simpara>
-</definition>
-<simpara>Every expression in the code may be a compile-time expression, but in most places this has no particular
-effect and is simply ignored. They are of significance only in computed property names, in index access
-expressions, as initializers of const variables and fields (as stated above) and when nested as an operand
-inside an expression at these locations.</simpara>
-</section>
-</chapter>
-<chapter xml:id="_statements">
-<title>Statements</title>
-<simpara>For all statements, we define the following pseudo properties:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>containingFunction</literal> </term>
-<listitem>
-<simpara>The function or method in which the statement is (indirectly) contained, this may be null.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>containingClass</literal> </term>
-<listitem>
-<simpara>The class in which the statement is (indirectly) contained, this may be null.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The expressions and statements are ordered, at first describing the constructs available in the 5th edition of ECMA-262
-referred to as [<link linkend="ECMA11a">ECMA11a</link>] in the following.
-The grammar snippets already use newer constructs in some cases.</simpara>
-<section xml:id="_ecmascript-5-statements" role="language-n4js">
-<title>ECMAScript 5 Statements</title>
-<simpara>N4JS supports the same statements as
-ECMAScript. Some of these statements are enhanced with annotations <xref linkend="_annotations"/> and type information.</simpara>
-<simpara>Although some statements may return a value which can be used via certain constructs such as <literal>eval</literal>), no type is inferred for any statement.
-The compiler will always create a warning if a statement is used instead of an expression.</simpara>
-<simpara>The following sections, therefore, do not define how to infer types for statement but how types and type annotations
-are used in these statements and the specific type constraints for a given statement.</simpara>
-<simpara>All syntax definitions taken from [<link linkend="ECMA11a">ECMA11a</link>] are repeated here for convenience reasons and in order to define temporary variables for simplifying constraint definitions.
-If non-terminals are not defined here, the definition specified in [<link linkend="ECMA11a">ECMA11a</link>] is to be used.</simpara>
-<section xml:id="_function-or-field-accessor-bodies">
-<title>Function or Field Accessor Bodies</title>
-<requirement xml:id="IDE-126">
-<title>Dead Code</title>
-<simpara>
-<anchor xml:id="Req-IDE-126" xreflabel="[Req-IDE-126]"/>
-<emphasis role="strong">Requirement: IDE-126:</emphasis>
-<link linkend="Req-IDE-126">Dead Code</link> (ver. 1)</simpara>
- <simpara>
-
-For all statements in a function or field accessor (getter/setter) body, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Statements appearing directly after return, throw, break, or continue statements (in the same block) are considered to be dead code and a warning is issued in these cases.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="_variable-statement">
-<title>Variable Statement</title>
-<bridgehead xml:id="variable-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>A var statement can declare the type of the variable with a type
-reference. This is described with the following grammar similar to
-[<link linkend="ECMA11a">ECMA11a(p.S12.2, p.p.87)</link>]:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">VariableStatement <In, Yield>:
- =>({VariableStatement}
- 'var'
- )
- varDeclsOrBindings+=VariableDeclarationOrBinding<In,Yield,false> (',' varDeclsOrBindings+=VariableDeclarationOrBinding<In,Yield,false>)* Semi
-;
-
-VariableDeclarationOrBinding <In, Yield, OptionalInit>:
- VariableBinding<In,Yield,OptionalInit>
- | VariableDeclaration<In,Yield,true>
-;
-
-VariableBinding <In, Yield, OptionalInit>:
- => pattern=BindingPattern<Yield> (
- <OptionalInit> ('=' expression=AssignmentExpression<In,Yield>)?
- | <!OptionalInit> '=' expression=AssignmentExpression<In,Yield>
- )
-;
-
-VariableDeclaration <In, Yield, AllowType>:
- {VariableDeclaration} VariableDeclarationImpl<In,Yield,AllowType>;
-
-fragment VariableDeclarationImpl <In, Yield, AllowType>*:
- annotations+=Annotation*
- (
- <AllowType> =>(
- name=BindingIdentifier<Yield> ColonSepTypeRef?
- ) ('=' expression=AssignmentExpression<In,Yield>)?
- | <!AllowType> =>(
- name=BindingIdentifier<Yield>
- ) ('=' expression=AssignmentExpression<In,Yield>)?
- )
-;</programlisting>
-<example>
-<title>Variable Statement</title>
-<programlisting language="n4js" linenumbering="unnumbered">var any: any;
-// any.type := any
-
-var anyNull = null;
-// anyNull.type := any
-
-var s: string;
-// s.type := string
-
-var init = "Hi";
-// init.type := string
-
-const MESSAGE = "Hello World";
-// MESSAGE.type := string</programlisting>
-</example>
-<bridgehead xml:id="variable-statement-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>From a model and type inference point of view, variable and constant statements and declarations are similar except that the pseudo property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi></math> is set to false for variables and true for constants.
-Also see exported variable statement (<xref linkend="_export-statement"/>) and constant statement and declaration (<xref linkend="_const"/>).</simpara>
-<requirement xml:id="IDE-127">
-<title>Variable declaration</title>
-<simpara>
-<anchor xml:id="Req-IDE-127" xreflabel="[Req-IDE-127]"/>
-<emphasis role="strong">Requirement: IDE-127:</emphasis>
-<link linkend="Req-IDE-127">Variable declaration</link> (ver. 1)</simpara>
- <simpara>
-
-For a given variable declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The type of the initializer expression must conform to the declared type:</simpara>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle><mo>∧</mo><mi>d</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mo>≠</mo><mstyle mathvariant="monospace"><mtext>null</mtext></mstyle></math><?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>→</mo><mi>Γ</mi><mo>⊢</mo><mi>d</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>Γ</mi><mo>⊢</mo><mi>d</mi><mo>.</mo><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>a</mi><mi>r</mi><mi>e</mi><mi>d</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>The initializer expression should not contain a reference to <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>d</mi></math> except where the reference is contained in a class expression or function expression and
-the class is not immediately initialized or the function is not immediately invoked.
-In these cases, the code is executed later and the self-reference is not a problem.<?asciidoc-br?>
-To clarify: <emphasis>should not</emphasis> means that only a warning will be produced.</simpara>
-</listitem>
-</itemizedlist>
-<programlisting language="n4js" linenumbering="unnumbered">// not ok (simple case)
-var n = n + 1;
-
-// ok (class expression not fully supported)
-// var cls1 = class { static sfield1 = "hello"; field2 = cls1.sfield1; };
-
-// not ok, immediately instantiated (class expression not fully supported)
-// var cls2 = new class { field1 = "hello"; field2 = cls2.field1; };
-
-// ok
-var fun1 = function() : number { var x = fun1; return -42; };
-
-// not ok, immediately invoked
-var fun2 = function() : number { var x = fun2; return -42; }();</programlisting>
-<simpara>The variable statement may contain array or object destructuring patterns, see <xref linkend="_array-and-object-destructuring"/> for details.</simpara>
-</requirement>
-<bridgehead xml:id="variable-statement-type-inference" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type of a variable is the type of its declaration:</simpara>
-
-<simpara>The type of a variable declaration is either the declared type or the inferred type of the initializer expression:</simpara>
-
-</section>
-<section xml:id="_if-statement" role="language-n4js">
-<title>If Statement</title>
-<bridgehead xml:id="if-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S12.5, p.p.89)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">IfStatement <Yield>:
- 'if' '(' expression=Expression<In=true,Yield> ')'
- ifStmt=Statement<Yield>
- (=> 'else' elseStmt=Statement<Yield>)?;</programlisting>
-<bridgehead xml:id="if-statement-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>There are no specific constraints defined for the condition, the ECMAScript operation <literal>ToBoolean</literal> [<link linkend="ECMA11a">ECMA11a(p.S9.2, p.p.43)</link>] is used to convert any type to boolean.</simpara>
-<requirement xml:id="IDE-128">
-<title>If Statement</title>
-<simpara>
-<anchor xml:id="Req-IDE-128" xreflabel="[Req-IDE-128]"/>
-<emphasis role="strong">Requirement: IDE-128:</emphasis>
-<link linkend="Req-IDE-128">If Statement</link> (ver. 1)</simpara>
- <simpara>
-
-In N4JS, the expression of an if statement must not evaluate to <literal>void</literal>.
-If the expressions is a function call in particular, the called function must not be declared to return <literal>void</literal>.</simpara>
-</requirement>
-</section>
-<section xml:id="_iteration-statements">
-<title>Iteration Statements</title>
-<bridgehead xml:id="iterations-statements-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S12.6, p.p.90ff)</link>]</simpara>
-<simpara>The syntax already considers the for-of style described in <xref linkend="_for-of-statement"/>.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">IterationStatement <Yield>:
- DoStatement<Yield>
- | WhileStatement<Yield>
- | ForStatement<Yield>
-;
-
-DoStatement <Yield>: 'do' statement=Statement<Yield> 'while' '(' expression=Expression<In=true,Yield> ')' => Semi?;
-WhileStatement <Yield>: 'while' '(' expression=Expression<In=true,Yield> ')' statement=Statement<Yield>;
-
-ForStatement <Yield>:
- {ForStatement} 'for' '('
- (
- // this is not in the spec as far as I can tell, but there are tests that rely on this to be valid JS
- =>(initExpr=LetIdentifierRef forIn?='in' expression=Expression<In=true,Yield> ')')
- | ( ->varStmtKeyword=VariableStatementKeyword
- (
- =>(varDeclsOrBindings+=BindingIdentifierAsVariableDeclaration<In=false,Yield> (forIn?='in' | forOf?='of') ->expression=AssignmentExpression<In=true,Yield>?)
- | varDeclsOrBindings+=VariableDeclarationOrBinding<In=false,Yield,OptionalInit=true>
- (
- (',' varDeclsOrBindings+=VariableDeclarationOrBinding<In=false,Yield,false>)* ';' expression=Expression<In=true,Yield>? ';' updateExpr=Expression<In=true,Yield>?
- | forIn?='in' expression=Expression<In=true,Yield>?
- | forOf?='of' expression=AssignmentExpression<In=true,Yield>?
- )
- )
- | initExpr=Expression<In=false,Yield>
- (
- ';' expression=Expression<In=true,Yield>? ';' updateExpr=Expression<In=true,Yield>?
- | forIn?='in' expression=Expression<In=true,Yield>?
- | forOf?='of' expression=AssignmentExpression<In=true,Yield>?
- )
- | ';' expression=Expression<In=true,Yield>? ';' updateExpr=Expression<In=true,Yield>?
- )
- ')'
- ) statement=Statement<Yield>
-;
-
-ContinueStatement <Yield>: {ContinueStatement} 'continue' (label=[LabelledStatement|BindingIdentifier<Yield>])? Semi;
-BreakStatement <Yield>: {BreakStatement} 'break' (label=[LabelledStatement|BindingIdentifier<Yield>])? Semi;</programlisting>
-<simpara>Since <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi><mi>a</mi><mi>r</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mfenced close=")" open="("><mi>s</mi></mfenced></math> are <literal>VariableStatement</literal>s as described in <xref linkend="_variable-statement"/>, the declared variables can be type annotated.</simpara>
-<tip>
-<simpara>Using for-in is not recommended, instead <literal>_each</literal> should be used.</simpara>
-</tip>
-<bridgehead xml:id="iterations-statements-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>There are no specific constraints defined for the condition, the
-ECMAScript operation <literal>ToBoolean</literal> [<link linkend="ECMA11a">ECMA11a(p.S9.2, p.p.43)</link>] is used to convert any type to boolean.</simpara>
-<requirement xml:id="IDE-129">
-<title>For-In-Statement Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-129" xreflabel="[Req-IDE-129]"/>
-<emphasis role="strong">Requirement: IDE-129:</emphasis>
-<link linkend="Req-IDE-129">For-In-Statement Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> the following conditions must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The type of the expression must be conform to object:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>Γ</mi><mo>⊢</mo><mi>f</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>union</mtext><mtext>Object,string,ArgumentType</mtext></mstyle></math></simpara>
-</listitem>
-<listitem>
-<simpara>Either a new loop variable must be declared or an rvalue must be provided as init expression:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∨</mo><mfenced close=")" open="("><mrow><mi>f</mi><mo>.</mo><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mi>i</mi><mi>s</mi><mi>R</mi><mi>V</mi><mi>a</mi><mi>l</mi><mi>u</mi><mi>e</mi><mfenced close=")" open="("><mrow><mi>f</mi><mo>.</mo><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi></mrow></mfenced></mrow></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara>The type of the loop variable must be a string (or a super type of string, i.e. any):</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd/><mtd><mrow><mo>(</mo><mrow><mi>f</mi><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><mi>f</mi><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle><mo>)</mo></mrow></mrow></mtd></mtr><mtr><mtd><mo>∨</mo></mtd><mtd><mrow><mo>(</mo><mrow><mi>f</mi><mo>.</mo><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>E</mi><mi>x</mi><mi>p</mi><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mi>Γ</mi><mo>⊢</mo><mstyle mathvariant="monospace"><mtext>string</mtext></mstyle><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>f</mi><mo>.</mo><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>)</mo></mrow></mrow></mtd></mtr></mtable></math>
-</listitem>
-</itemizedlist>
-</requirement>
-</section>
-<section xml:id="_return-statement" role="language-n4js">
-<title>Return Statement</title>
-<bridgehead xml:id="return-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>The returns statement is defined as in [<link linkend="ECMA11a">ECMA11a(p.S12.9, p.p.93)</link>] with</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ReturnStatement <Yield>:
- 'return' (expression=Expression<In=true,Yield>)? Semi;</programlisting>
-<bridgehead xml:id="return-statement-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-130">
-<title>Return statement</title>
-<simpara>
-<anchor xml:id="Req-IDE-130" xreflabel="[Req-IDE-130]"/>
-<emphasis role="strong">Requirement: IDE-130:</emphasis>
-<link linkend="Req-IDE-130">Return statement</link> (ver. 1)</simpara>
- <simpara>
-
-1. Expected type of expression in a return statement must be a sub type of the return type of the enclosing function:</simpara>
-<simpara>+</simpara>
-
-<simpara>Note that the expression may be evaluated to <literal>void</literal>.
-2. If enclosing function is declared to return <literal>void</literal>, then either
-* no return statement must be defined
-* return statement has no expression
-* type of expression of return statement is <literal>void</literal>
-3. If enclosing function is declared to to return a type different from <literal>void</literal>, then
-* all return statements must have a return expression
-* all control flows must either end with a return or throw statement
-4. Returns statements must be enclosed in a function.
-A return statement, for example, must not be a top-level statement.</simpara>
-</requirement>
-</section>
-<section xml:id="_with-statement">
-<title>With Statement</title>
-<bridgehead xml:id="with-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>The with statement is not allowed in N4JS, thus an error is issued.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">WithStatement <Yield>:
- 'with' '(' expression=Expression<In=true,Yield> ')'
- statement=Statement<Yield>;</programlisting>
-<bridgehead xml:id="with-statement-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>N4JS is based on strict mode and the with statement is not allowed in
-strict mode, cf. [<link linkend="ECMA11a">ECMA11a(p.S12.10.1, p.p.94)</link>].</simpara>
-<requirement xml:id="IDE-131">
-<title>With Statement</title>
-<simpara>
-<anchor xml:id="Req-IDE-131" xreflabel="[Req-IDE-131]"/>
-<emphasis role="strong">Requirement: IDE-131:</emphasis>
-<link linkend="Req-IDE-131">With Statement</link> (ver. 1)</simpara>
- <simpara>
-
-With statements are not allowed in N4JS or strict mode.</simpara>
-</requirement>
-</section>
-<section xml:id="_switch-statement">
-<title>Switch Statement</title>
-<bridgehead xml:id="switch-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S12.11, p.p.94ff)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">SwitchStatement <Yield>:
- 'switch' '(' expression=Expression<In=true,Yield> ')' '{'
- (cases+=CaseClause<Yield>)*
- ((cases+=DefaultClause<Yield>)
- (cases+=CaseClause<Yield>)*)? '}'
-;
-
-CaseClause <Yield>: 'case' expression=Expression<In=true,Yield> ':' (statements+=Statement<Yield>)*;
-DefaultClause <Yield>: {DefaultClause} 'default' ':' (statements+=Statement<Yield>)*;</programlisting>
-<bridgehead xml:id="switch-statement-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-132">
-<title>Switch Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-132" xreflabel="[Req-IDE-132]"/>
-<emphasis role="strong">Requirement: IDE-132:</emphasis>
-<link linkend="Req-IDE-132">Switch Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-For a given switch statement <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi></math>, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>For all cases <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mo>∈</mo><mi>s</mi><mo>.</mo><mi>c</mi><mi>a</mi><mi>s</mi><mi>e</mi><mi>s</mi></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi></math>===<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mo>.</mo><mi>e</mi><mi>x</mi><mi>p</mi><mi>r</mi></math> must be valid according to the constraints defined in <xref linkend="_equality-expression"/>.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-</section>
-<section xml:id="_throw-try-and-catch-statements">
-<title>Throw, Try, and Catch Statements</title>
-<bridgehead xml:id="throw-try-catch-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S12.13/14, p.p.96ff)</link>]</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ThrowStatement <Yield>:
- 'throw' expression=Expression<In=true,Yield> Semi;
-
-TryStatement <Yield>:
- 'try' block=Block<Yield>
- ((catch=CatchBlock<Yield> finally=FinallyBlock<Yield>?) | finally=FinallyBlock<Yield>)
-;
-
-CatchBlock <Yield>: {CatchBlock} 'catch' '(' catchVariable=CatchVariable<Yield> ')' block=Block<Yield>;
-
-CatchVariable <Yield>:
- =>bindingPattern=BindingPattern<Yield>
- | name=BindingIdentifier<Yield>
-;
-
-FinallyBlock <Yield>: {FinallyBlock} 'finally' block=Block<Yield>;</programlisting>
-<simpara>There must be not type annotation for the catch variable, as this would lead to the wrong assumption that a type can be specified.</simpara>
-<bridgehead xml:id="throw-try-catch-type-inference" renderas="sect4">Type Inference</bridgehead>
-<simpara>The type of the catch variable is always assumed to be <literal>any</literal>.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow/><mrow><mi>Γ</mi><mo>⊢</mo><mi>c</mi><mi>a</mi><mi>t</mi><mi>c</mi><mi>h</mi><mi>B</mi><mi>l</mi><mi>o</mi><mi>c</mi><mi>k</mi><mo>.</mo><mi>c</mi><mi>a</mi><mi>t</mi><mi>c</mi><mi>h</mi><mi>V</mi><mi>a</mi><mi>r</mi><mi>i</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi><mi>:</mi><mstyle mathvariant="monospace"><mtext>any</mtext></mstyle></mrow></mfrac></math>
-</section>
-<section xml:id="_debugger-statement">
-<title>Debugger Statement</title>
-<bridgehead xml:id="debugger-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.S12.15, p.p.97ff)</link>])</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">DebuggerStatement: {DebuggerStatement} 'debugger' Semi;</programlisting>
-<bridgehead xml:id="debugger-statement--semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>na</simpara>
-</section>
-</section>
-<section xml:id="_ecmascript-6-statements" role="language-n4js">
-<title>ECMAScript 6 Statements</title>
-<simpara>N4JS export and import statements are similar to ES6 with some minor d ifferences which are elaborated on below.</simpara>
-<section xml:id="_let">
-<title>Let</title>
-<simpara>Cf. [<link linkend="ECMA11a">ECMA11a(p.13.2.1)</link>], also <link xl:href="http://www.2ality.com/2015/02/es6-scoping.html">Rauschmayer, 2ality: <emphasis role="strong">Variables and scoping in ECMAScript 6</emphasis></link></simpara>
-</section>
-<section xml:id="_const">
-<title>Const</title>
-<simpara>Cf. [<link linkend="ECMA15a">ECMA15a(p.13.2.1)</link>], also <link xl:href="http://www.2ality.com/2015/02/es6-scoping.html">Rauschmayer, 2ality: <emphasis role="strong">Variables and scoping in ECMAScript 6</emphasis></link></simpara>
-<simpara>Additionally to the <literal>var</literal> statement, the <literal>const</literal> statement is supported.
-It allows for declaring variables which must be assigned to a value in the declaration and their value must not change.
-That is to say that constants are not allowed to be on the left-hand side of other assignments.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ConstStatement returns VariableStatement: 'const' varDecl+=ConstDeclaration ( ',' varDecl+=ConstDeclaration )* Semi;
-
-ConstDeclaration returns VariableDeclaration: typeRef=TypeRef? name=IDENTIFIER const?='=' expression=AssignmentExpression;</programlisting>
-<bridgehead xml:id="const-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>A const variable statement is more or less a normal variable statement (see <xref linkend="_variable-statement"/>), except that all variables declared by that
-statement are not writable (cf. <xref linkend="Req-IDE-121"/>).
-This is similar to constant data fields (cf. <xref linkend="_assignment-modifiers"/>).</simpara>
-<requirement xml:id="IDE-133">
-<title>Writability of const variables</title>
-<simpara>
-<anchor xml:id="Req-IDE-133" xreflabel="[Req-IDE-133]"/>
-<emphasis role="strong">Requirement: IDE-133:</emphasis>
-<link linkend="Req-IDE-133">Writability of const variables</link> (ver. 1)</simpara>
- <simpara>
-
-All variable declarations of a const variable statement
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi></math> are not writeable:
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>v</mi><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mo>∈</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>S</mi><mi>t</mi><mi>m</mi><mi>t</mi><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mi>:</mi><mo>¬</mo><mi>v</mi><mi>d</mi><mi>e</mi><mi>c</mi><mi>l</mi><mo>.</mo><mi>w</mi><mi>r</mi><mi>i</mi><mi>t</mi><mi>a</mi><mi>b</mi><mi>l</mi><mi>e</mi></math></simpara>
-</requirement>
-</section>
-<section xml:id="_for-of-statement">
-<title><literal>for …​ of</literal> statement</title>
-<simpara>ES6 introduced a new form of <literal>for</literal> statement: <literal>for …​ of</literal> to iterate over the elements of an <literal>Iterable</literal>, cf. <xref linkend="_iterablen"/>.</simpara>
-<bridgehead xml:id="for-of-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>See <xref linkend="_iteration-statements"/></simpara>
-<bridgehead xml:id="for-of-statement-semantics" renderas="sect4">Semantics</bridgehead>
-<requirement xml:id="IDE-134">
-<title>for …​ of statement</title>
-<simpara>
-<anchor xml:id="Req-IDE-134" xreflabel="[Req-IDE-134]"/>
-<emphasis role="strong">Requirement: IDE-134:</emphasis>
-<link linkend="Req-IDE-134">for ... of statement</link> (ver. 1)</simpara>
- <simpara>
-
-For a given <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi></math> the following conditions must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The value provided after <literal>of</literal> in a <literal>for …​ of</literal> statement must be a subtype of <literal>Iterable<?></literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Either a new loop variable must be declared or an rvalue must be provided as init expression:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mo>.</mo><mi>v</mi><mi>a</mi><mi>r</mi><mi>D</mi><mi>e</mi><mi>c</mi><mi>l</mi><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∨</mo><mfenced close=")" open="("><mrow><mi>f</mi><mo>.</mo><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mo>≠</mo><mi>n</mi><mi>u</mi><mi>l</mi><mi>l</mi><mo>∧</mo><mi>i</mi><mi>s</mi><mi>R</mi><mi>V</mi><mi>a</mi><mi>l</mi><mi>u</mi><mi>e</mi><mfenced close=")" open="("><mrow><mi>f</mi><mo>.</mo><mi>i</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi></mrow></mfenced></mrow></mfenced></math></simpara>
-</listitem>
-<listitem>
-<simpara>If a new variable <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi></math> is declared before <literal>of</literal> and it has a declared type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>, the value provided after must be a subtype of <literal>Iterable<?extendsT></literal>.
-If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi></math> does not have a declared type, the type of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>v</mi></math> is inferred to the type of the first type argument of the actual type of the value provided after <literal>of</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>If a previously-declared variable is referenced before with a declared or inferred type of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>, the value provided after <literal>of</literal> must be a subtype of <literal>Iterable<?extendsT></literal>.</simpara>
-</listitem>
-</orderedlist>
-<note>
-<simpara><literal>Iterable</literal> is structurally typed on definition-site so non-N4JS types can meet the above requirements by simply implementing the only method in interface <literal>Iterable</literal> (with a correct return type).</simpara>
-</note>
-<note>
-<simpara>The first of the above constraints (the type required by the ’of’ part in a <literal>for …​ of</literal> loop is <literal>Iterable</literal>) was changed during the definition of ECMAScript 6.
-This is implemented differently in separate implementations and even in different versions of the same implementation (for instance in different versions of V8).
-Older implementations require an <literal>Iterator</literal> or accept both <literal>Iterator</literal> an or <literal>Iterable</literal>.</simpara>
-</note>
-<simpara>Requiring an <literal>Iterable</literal> and not accepting a plain <literal>Iterator</literal> seems to be the final decision (as of Dec. 2014).
-For reference, see abstract operations <literal>GetIterator</literal> in [<link linkend="ECMA15a">ECMA15a(p.S7.4.2)</link>] and "CheckIterable" [<link linkend="ECMA15a">ECMA15a(p.S7.4.1)</link>] and their
-application in "ForIn/OfExpressionEvaluation" [<link linkend="ECMA15a">ECMA15a(p.S13.6.4.8)</link>] and <literal>CheckIterable</literal> and their application in <literal>ForIn/OfExpressionEvaluation</literal>.
-See also a related blog post <footnote><simpara>available at: <link xl:href="http://www.2ality.com/2013/06/iterators-generators.html">http://www.2ality.com/2013/06/iterators-generators.html</link></simpara></footnote> that is kept up to date with changes to ECMAScript 6:</simpara>
-<blockquote>
-<simpara><emphasis>ECMAScript 6 has a new loop, for-of. That loop works with iterables. Before we can use it with createArrayIterator(), we need to turn the result into an iterable.</emphasis></simpara>
-</blockquote>
-<simpara>An array or object destructuring pattern may be used left of the <literal>of</literal>.
-This is used to destructure the elements of the <literal>Iterable</literal> on the right-hand side (not the <literal>Iterable</literal> itself).
-For detais, see <xref linkend="_array-and-object-destructuring"/>.</simpara>
-</requirement>
-</section>
-<section xml:id="_import-statement">
-<title>Import Statement</title>
-<simpara>Cf. ES6 import [<link linkend="ECMA15a">ECMA15a(p.15.2.2)</link>], see also <link xl:href="https://babeljs.io/docs/usage/modules/">https://babeljs.io/docs/usage/modules/</link></simpara>
-<bridgehead xml:id="import-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>The grammar of import declarations is defined as follows:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ImportDeclaration:
- {ImportDeclaration}
- ImportDeclarationImpl
-;
-
-fragment ImportDeclarationImpl*:
- 'import' (
- ImportClause importFrom?='from'
- )? module=[types::TModule|ModuleSpecifier] Semi
-;
-
-fragment ImportClause*:
- importSpecifiers+=DefaultImportSpecifier (',' ImportSpecifiersExceptDefault)?
- | ImportSpecifiersExceptDefault
-;
-
-fragment ImportSpecifiersExceptDefault*:
- importSpecifiers+=NamespaceImportSpecifier
- | '{' (importSpecifiers+=NamedImportSpecifier (',' importSpecifiers+=NamedImportSpecifier)* ','?)? '}'
-;
-
-NamedImportSpecifier:
- importedElement=[types::TExportableElement|BindingIdentifier<Yield=false>]
- | importedElement=[types::TExportableElement|IdentifierName] 'as' alias=BindingIdentifier<Yield=false>
-;
-
-DefaultImportSpecifier:
- importedElement=[types::TExportableElement|BindingIdentifier<Yield=false>]
-;
-
-NamespaceImportSpecifier: {NamespaceImportSpecifier} '*' 'as' alias=BindingIdentifier<false> (declaredDynamic?='+')?;
-
-ModuleSpecifier: STRING;</programlisting>
-<simpara>These are the properties of import declaration which can be specified by the user:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>annotations</literal> </term>
-<listitem>
-<simpara>Arbitrary annotations, see <xref linkend="_annotations"/> and below for details.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>importSpecifiers</literal> </term>
-<listitem>
-<simpara>The elements to be imported with their names.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Also see compilation as described in <xref linkend="_modules"/>, for semantics see <xref linkend="import-statement-semantics"/>.</simpara>
-<example>
-<title>Import</title>
-<programlisting language="n4js" linenumbering="unnumbered">import A from "p/A"
-import {C,D,E} from "p/E"
-import * as F from "p/F"
-import {A as G} from "p/G"
-import {A as H, B as I} from "p/H"</programlisting>
-</example>
-<bridgehead xml:id="import-statement-semantics" xreflabel="Import Statement Semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>Import statements are used to import identifiable elements from another module.
-Identifiable elements are</simpara>
-<itemizedlist>
-<listitem>
-<simpara>types (via their type declaration), in particular</simpara>
-<itemizedlist>
-<listitem>
-<simpara>classifiers (classes, interfaces)</simpara>
-</listitem>
-<listitem>
-<simpara>functions</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>variables and constants.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The module to import from is identified by the string literal following keyword <literal>from</literal>.
-This string must be a valid</simpara>
-<itemizedlist>
-<listitem>
-<simpara>complete module specifier <footnote><simpara>For more details on module specifiers, see <xref linkend="_qualified-names"/>.</simpara></footnote>:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> import {A} from "ProjectA/a/b/c/M"</programlisting>
-</listitem>
-<listitem>
-<simpara>plain module specifier:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> import {A} from "a/b/c/M"</programlisting>
-</listitem>
-<listitem>
-<simpara>or project name only, assuming the project defines a main module in its <literal>package.json</literal> file (using the <literal>mainModule</literal> package.json property, see <xref linkend="package-json-mainModule"/>):</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> import {A} from "ProjectA"</programlisting>
-</listitem>
-</itemizedlist>
-<simpara>For choosing the element to import, there are the exact same options as in ECMAScript6:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>named imports select one or more elements by name, optionally introducing a local alias:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> import {C} from "M"
- import {D as MyD} from "M"
- import {E, F as MyF, G, H} from "M"</programlisting>
-</listitem>
-<listitem>
-<simpara>namespace imports select all elements of the remote module for import and define a namespace name; the imported elements are then accessed via the namespace name:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> import * as N from "M"
- var c: N.C = new N.C();</programlisting>
-</listitem>
-<listitem>
-<simpara>default imports select whatever element was exported by the remote module as the default (there can be at most one default export per module):</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> import C from "M"</programlisting>
-</listitem>
-<listitem>
-<simpara>namespace imports provide access to the default export:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered"> import * as N from "M"
- var c: N.default = new N.default();</programlisting>
-</listitem>
-</itemizedlist>
-<simpara>The following constraints are defined on a (non-dynamic) import statement <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The imported module needs to be accessible from the current project.</simpara>
-</listitem>
-<listitem>
-<simpara>The imported declarations need to be accessible from the current module.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For named imports, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>No declaration must be imported multiple times, even if aliases are used.</simpara>
-</listitem>
-<listitem>
-<simpara>The names must be unique in the module. They must not conflict with each other or locally declared variables, types, or functions.</simpara>
-</listitem>
-<listitem>
-<simpara>Declarations imported via named imports are accessible only via used name (or alias) and not via original name directly.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For wildcard imports, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Only one namespace import can be used per (target) module, even if different namespace name is used.</simpara>
-</listitem>
-<listitem>
-<simpara>The namespace name must be unique in the module. They must not conflict with each other or locally declared variables, types, or functions.</simpara>
-</listitem>
-<listitem>
-<simpara>Declarations imported via namespace import are accessible via namespace only and not with original name directly.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For namespace imports, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If the referenced module is a plain <literal>js</literal> file, a warning will be created to use the dynamic import instead.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For default imports, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The referenced module must have a default export.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Cross-cutting constraints:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>No declaration can be imported via named import and namespace import at the same time.</simpara>
-</listitem>
-</itemizedlist>
-<example>
-<title>Imports</title>
-<simpara>Imports cannot be duplicated:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import * as A from 'A';
-import * as A from 'A';//error, duplicated import statement
-
-import B from 'B';
-import B from 'B';//error, duplicated import statement</programlisting>
-<simpara>Given element cannot be imported multiple times:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import * as A1 from 'A';
-import * as A2 from 'A';//error, elements from A already imported in A1
-
-import B from 'B';
-import B as B1 from 'B';//error, B/B is already imported as B
-
-import C as C1 from 'C';
-import C from 'C';//error, C/C is already imported as C1
-
-import D as D1 from 'D';
-import D as D2 from 'D';//error, D/D is already imported as D1
-
-import * as NE from 'E';
-import E from 'E';//error, E/E is already imported as NE.E
-
-import F from 'F';
-import * as NF from 'F';//error, F/F is already imported as F</programlisting>
-<simpara><?asciidoc-pagebreak?></simpara>
-<simpara>Names used in imports must not not conflict with each other or local
-declarations:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import * as A from 'A1';
-import * as A from 'A2';//A is already used as namespace for A1
-
-import B from 'B1';
-import B1 as B from 'B2';//B us already used as import B/B1
-
-import C1 as C from 'C1';
-import * as C from 'C2'; //C is already used as import C1/C1
-
-import * as D from 'D1';
-import D2 as D from 'D2';//D is already used as namespace for D1
-
-import E from 'E';
-var E: any; // conflict with named import E/E
-
-import * as F from 'F';
-var F: any; // conflict with namespace F</programlisting>
-<simpara>Using named imports, aliases and namespaces allows to refer to mulitple
-types of the same name such as <literal>A/A</literal>, <literal>B/A</literal> and <literal>C/A</literal>:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import A from 'A';// local name A referencess to A/A
-import A as B from 'B';//local name B referencess to B/A
-import * as C from 'C';//local name C.A referencess to C/A</programlisting>
-<simpara><?asciidoc-pagebreak?></simpara>
-<simpara>If a declaration has been imported with an alias or namespace, it is not
-accessible via its original name:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">import * as B from 'A1';
-import A2 as C from 'A2';
-
-var a1_bad: A1;//error, A1/A1 is not directly accessible with original name
-var a1_correct: B.A1;// A1/A1 is accessible via namespace B
-var a2_bad: A2;//error, A2/A2 is not directly accessible with original name
-var a2_correct: C;// A2/A2 is accessible via alias C</programlisting>
-</example>
-<section xml:id="Dynamic_Imports">
-<title>Dynamic Imports</title>
-<simpara>N4JS extends the ES6 module import in order that modules without a <literal>n4jsd</literal> or <literal>n4js</literal> file (plain <literal>js</literal> modules) can be imported.
-This is done by adding <literal>+</literal> to the name of the named import. This form of compile-time import without type information is not
-to be confused with import calls as described in <xref linkend="Import_Calls"/>, which are sometimes referred to as "dynamic import" as well.</simpara>
-<requirement xml:id="IDE-136">
-<title>Dynamic Import</title>
-<simpara>
-<anchor xml:id="Req-IDE-136" xreflabel="[Req-IDE-136]"/>
-<emphasis role="strong">Requirement: IDE-136:</emphasis>
-<link linkend="Req-IDE-136">Dynamic Import</link> (ver. 1)</simpara>
- <simpara>
-
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> be an import
-statement <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> with a dynamic namespace specifier. The
-following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi></math> must not reference an <literal>n4js</literal> file.</simpara>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi></math> references an <literal>n4jsd</literal> file, a warning is
-to be created.</simpara>
-</listitem>
-<listitem>
-<simpara>If the file referenced by <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi><mo>.</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi></math> is not found, an
-error is created just as in the static case.</simpara>
-</listitem>
-</orderedlist>
-<simpara>These constraints define the error level when using dynamic import: we receive no error for <literal>js</literal>, a warning for <literal>n4jsd</literal>, and an error for <literal>n4js</literal> files.
-The idea behind these distinct error levels is as follows:<?asciidoc-br?>
-If only a plain <literal>js</literal> file is available, using the dynamic import is the only way to access elements from the <literal>js</literal> module.
-This might be an unsafe way, but it allows the access and simplifies the first steps.
-An <literal>n4jsd</literal> file may then be made available either by the developer using the <literal>js</literal> module or by a third-party library.
-In this case, we do not want to break existing code.
-There is only a warning created in the case of an available <literal>n4jsd</literal> file and a <literal>js</literal> file still must be provided by the user.
-Having an <literal>n4js</literal> file is a completely different story; no <literal>n4jsd</literal> file is required, no <literal>js</literal> file is needed
-(since the transpiler creates one from the <literal>n4js</literal> file) and there is absolutely no reason to use the module dynamically.</simpara>
-</requirement>
-</section>
-<section xml:id="_immutabilaty-of-imports">
-<title>Immutabilaty of Imports</title>
-<simpara>Imports create always immutable bindings, c.f.
-[<link linkend="ECMA15a">ECMA15a(p.8.1.1.5)</link>]
-<link xl:href="http://www.ecma-international.org/ecma-262/6.0/index.html#sec-createimportbinding">http://www.ecma-international.org/ecma-262/6.0/index.html#sec-createimportbinding</link></simpara>
-<requirement xml:id="IDE-137">
-<title>Immutable Import</title>
-<simpara>
-<anchor xml:id="Req-IDE-137" xreflabel="[Req-IDE-137]"/>
-<emphasis role="strong">Requirement: IDE-137:</emphasis>
-<link linkend="Req-IDE-137">Immutable Import</link> (ver. 1)</simpara>
- <simpara>
-
-Let <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> be a binding to an imported element.
-It is an error if</simpara>
-<itemizedlist>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> occurs on the left-hand side as the assignment-target of an assignment expression (this also includes any level in a destructuring pattern on the left-hand side),</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> as a direct argument of a postfix operator (<literal>i++</literal>/<literal>i--</literal>),</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> as a direct argument of a <literal>delete</literal> operator,</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math> as a direct argument of the <literal>increment</literal> or <literal>decrement</literal> unary operator (<literal>i++</literal>/<literal>i--</literal>)</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-</section>
-</section>
-<section xml:id="_export-statement">
-<title>Export Statement</title>
-<simpara>Cf. ES6 import [<link linkend="ECMA15a">ECMA15a(p.15.2.3)</link>]</simpara>
-<bridgehead xml:id="export-statement-syntax" renderas="sect4">Syntax</bridgehead>
-<simpara>Grammar of export declarations is defined as follows:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">ExportDeclaration:
- {ExportDeclaration}
- ExportDeclarationImpl
-;
-
-fragment ExportDeclarationImpl*:
- 'export' (
- wildcardExport?='*' ExportFromClause Semi
- | ExportClause ->ExportFromClause? Semi
- | exportedElement=ExportableElement
- | defaultExport?='default' (->exportedElement=ExportableElement | defaultExportedExpression=AssignmentExpression<In=true,Yield=false> Semi)
- )
-;
-
-fragment ExportFromClause*:
- 'from' reexportedFrom=[types::TModule|ModuleSpecifier]
-;
-
-fragment ExportClause*:
- '{'
- (namedExports+=ExportSpecifier (',' namedExports+=ExportSpecifier)* ','?)?
- '}'
-;
-
-ExportSpecifier:
- element=IdentifierRef<Yield=false> ('as' alias=IdentifierName)?
-;
-
-ExportableElement:
- N4ClassDeclaration<Yield=false>
- | N4InterfaceDeclaration<Yield=false>
- | N4EnumDeclaration<Yield=false>
- | ExportedFunctionDeclaration<Yield=false>
- | ExportedVariableStatement
-;</programlisting>
-<simpara>These are the properties of export declaration, which can be specified by the user:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>exportedElement</literal> </term>
-<listitem>
-<simpara>The element to be exported, can be a declaration or a variable/const statement.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<example>
-<title>Export</title>
-<programlisting language="n4js" linenumbering="unnumbered">export public class A{}
-export interface B{}
-export function foo() {}
-export var a;
-export const c="Hello";</programlisting>
-</example>
-<bridgehead xml:id="export-statement-semantics" renderas="sect4">Semantics</bridgehead>
-<simpara>With regard to type inference, export statements are not handled at all.
-Only the exported element is inferred and the <literal>export</literal> keyword is ignored.</simpara>
-<simpara>In order to use types defined in other compilation units, these types have to be explicitly imported with an import statement.</simpara>
-<simpara>Imported namespaces cannot be exported.</simpara>
-<simpara>Declared elements (types, variables, functions) are usually only visible outside the declaring module if the elements are exported and imported (by the using module, cf. <xref linkend="_import-statement"/>).</simpara>
-<simpara>Some special components (runtime environment and libraries, cf. <xref linkend="_runtime-environment-and-runtime-libraries"/>, may export elements globally.
-This is done by annotating the export (or the whole module) with <literal>@Global</literal>, see <xref linkend="_global-definitions"/> for details.</simpara>
-<simpara>By adding <literal>default</literal> after the keyword <literal>export</literal>, the identifiable element can be exported as ’the default’.
-This can then be imported from other modules via default imports (see <xref linkend="_import-statement"/>).</simpara>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_annotations">
-<title>Annotations</title>
-<section xml:id="_introduction-2" role="language-n4js">
-<title>Introduction</title>
-<simpara>Annotations are used to further define meta properties of language elements such as types, variables and functions.
-These annotations are used by the compiler and validator to prohibit the developer from introducing constructs which are either not allowed or are unnecessary in certain contexts.</simpara>
-<simpara>Since annotations are to be processed by the compiler and the compilation cannot be extended by third-party users for security reasons, annotations cannot be defined by developers.
-Instead, the compiler comes with a predefined set of annotations which are summarized here.</simpara>
-<section xml:id="_syntax-13">
-<title>Syntax</title>
-<simpara>Annotations are used similarly as in Java (although new annotations cannot be defined by the user).
-They are formally defined as follows:</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Annotation:'@' AnnotationNoAtSign;
-ScriptAnnotation returns Annotation: '@@' AnnotationNoAtSign;
-
-AnnotationNoAtSign returns Annotation:
- name=AnnotationName (=> '(' (args+=AnnotationArgument (',' args+=AnnotationArgument)*)? ')')?;
-
-AnnotationArgument:
- LiteralAnnotationArgument | TypeRefAnnotationArgument
-;
-
-LiteralAnnotationArgument:
- literal=Literal
-;
-
-TypeRefAnnotationArgument:
- typeRef=TypeRef
-;</programlisting>
-</section>
-<section xml:id="_properties-7">
-<title>Properties</title>
-<simpara>We use the map notation for retrieving annotation properties and values from a list of annotations,
-for example <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>x</mi><mo>.</mo><mi>a</mi><mi>n</mi><mi>n</mi><mi>o</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>s</mi><mfenced close="]" open="["><mrow><mi>R</mi><mi>e</mi><mi>q</mi><mi>u</mi><mi>i</mi><mi>r</mi><mi>e</mi><mi>d</mi></mrow></mfenced></math>, or shorter <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>x</mi><mi>@</mi><mi>R</mi><mi>e</mi><mi>q</mi><mi>u</mi><mi>i</mi><mi>r</mi><mi>e</mi><mi>d</mi></math>.</simpara>
-<simpara><?asciidoc-pagebreak?></simpara>
-</section>
-<section xml:id="_element-specific-annotations">
-<title>Element-Specific Annotations</title>
-<simpara>The following annotations are element-specific and are explained in the corresponding sections:</simpara>
-<table frame="all" rowsep="1" colsep="1">
-<title>Element-Specific Annotations</title>
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<thead>
-<row>
-<entry align="left" valign="top">Annotation</entry>
-<entry align="center" valign="top">Element Types</entry>
-<entry align="left" valign="top">Section</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Internal</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>TypeDefiningElement, Member, Function, Export</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_access-control"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Undefined</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Variable</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_undefined-type"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@StringBased</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Enum</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_string-based-enums"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Final</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Class, Member</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_final-methods"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Spec</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>FPar</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="Req-IDE-59"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Override</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Method</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_redefinition-of-members"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Promisifiable</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Function</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_promisifiable-functions"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Promisify</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>CallExpression</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_promisifiable-functions"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@This</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Function</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_this-keyword"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@N4JS</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Class, Export Statement</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_external-declarations"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@IgnoreImplementation</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Script, ExportDeclaration, ExportableElement</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_external-declarations"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Global</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>External Declaration</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_global-definitions"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@ProvidedByRuntime</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>External Declaration</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_runtime-definitions"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@TestAPI</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>TypeDefiningElement, Member</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_test-support"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Polyfill</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Class</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_polyfill-definitions"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@StaticPolyfill</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Class</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_static-polyfill-definitions"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@StaticPolyfillAware</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Script</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_static-polyfill-definitions"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@StaticPolyfillModule</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Script</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><xref linkend="_static-polyfill-definitions"/></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara><literal>@Transient</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><literal>Field</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><footnote><simpara>intended for internal use only; will be removed</simpara></footnote></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-</section>
-<section xml:id="_general-annotations">
-<title>General Annotations</title>
-<section xml:id="_idebug">
-<title>IDEBUG</title>
-<simpara><literal>@IDEBUG</literal> is an annotation similar to Java’s <literal>@SuppressWarnings</literal>.
-It changes the severity of an issue from an error to a warning so that code can be compiled regardless of validation errors.
-This is to be used for known IDE bugs only.</simpara>
-</section>
-</section>
-<section xml:id="idebug-syntax">
-<title>Syntax</title>
-<programlisting language="xtext" linenumbering="unnumbered">'@IDEBUG' '(' bugID = INT ',' errorMessage=STRING ')'</programlisting>
-<simpara>The annotation is defined transitively and repeatable on script, type declaration, function and method level.</simpara>
-<section xml:id="_semantics-11">
-<title>Semantics</title>
-<simpara>This annotation will cause errors issued in the scope of the annotation (in the defined script, type, or method) to be transformed to warnings if their message text is similar to the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>r</mi><mi>r</mi><mi>o</mi><mi>r</mi><mi>M</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>a</mi><mi>g</mi><mi>e</mi></math> text.
-If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>e</mi><mi>r</mi><mi>r</mi><mi>o</mi><mi>r</mi><mi>M</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>a</mi><mi>g</mi><mi>e</mi></math> ends with <literal>…</literal> (three dots as a single character, created by Eclipse to abbreviate messages), then the error’s message text must start with the specified text.</simpara>
-<simpara>If no matching error is found, the annotation itself will issue an error.</simpara>
-<example xml:id="ex:IDEBUG">
-<title>IDEBUG Example</title>
-<simpara>In the following code snippet, two errors are to be transformed to warnings.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">export class TestDataBridge with IModuleTest {
- @IDEBUG(166, "{function(number):void} is not a subtype of {function(T):void}.") <co xml:id="CO6-1"/>
- @IDEBUG(91, "Incorrect number of arguments: expected 1, got 2.") <co xml:id="CO6-2"/>
- @Override public run(): void {
- var foo = new Foo(),
- cb = function(val: number): void {},
- db = DataBridge.<number>bind(foo, "bar");
- db.add(cb); <co xml:id="CO6-3"/>
- Assert.isTrue(called);
- }
-}</programlisting>
-<calloutlist>
-<callout arearefs="CO6-1">
-<para>The annotation transforms the error <literal>{function(number):void} is not a subtype of {function(T):void}</literal> into a warning with the following text:</para>
-<programlisting language="n4js" linenumbering="unnumbered">IDEBUG-166: {function(number):void} is not a subtype of {function(T):void}.</programlisting>
-<simpara>where <literal>IDEBUG-166</literal> refers to the corresponding bug report, that is <link xl:href="https://github.com/NumberFour/n4js/issues/166">IDEBUG-166</link>.</simpara>
-</callout>
-<callout arearefs="CO6-2">
-<para>This annotation was proposed as a workaround for <link xl:href="https://github.com/NumberFour/n4js/issues/91">IDEBUG-91</link> which has been fixed.<?asciidoc-br?>
-No error message is produced and an error will be issued on this line instead:</para>
-<programlisting language="n4js" linenumbering="unnumbered">No matching error found, apparently bug IDEBUG-91 has been fixed or does not occur here.</programlisting>
-</callout>
-<callout arearefs="CO6-3">
-<para>The first error occurs since there is a bug in the IDE type system (as of writing this example) where type arguments are not correctly bound in the case of function expressions used as callback methods.</para>
-</callout>
-</calloutlist>
-</example>
-</section>
-<section xml:id="_suppress-warnings">
-<title>Suppress Warnings</title>
-<tip>
-<simpara>This is not part of the current version</simpara>
-</tip>
-</section>
-</section>
-</section>
-<section xml:id="_declaration-of-annotations">
-<title>Declaration of Annotations</title>
-<tip>
-<simpara>This is not part of the current version</simpara>
-</tip>
-</section>
-</chapter>
-<chapter xml:id="_extended-fetaures">
-<title>Extended Fetaures</title>
-<section xml:id="_array-and-object-destructuring" role="language-n4js">
-<title>Array and Object Destructuring</title>
-<simpara>N4JS supports array and object destructuring as provided in ES6.
-This is used to conveniently assign selected elements of an array or object to a number of newly-declared or pre-existing variables or to further destructure them by using nested
-destructuring patterns <footnote><simpara>Further reading on <link linkend="_acronyms">DI</link> Basics: [<link linkend="Fowler04b">Fowler04b</link>; <link linkend="Prasanna09a">Prasanna09a</link>], Verification [<link linkend="Zhu13a">Zhu13a</link>; <link linkend="Hudli13a">Hudli13a</link>], Frameworks [<link linkend="Lesiecki08a">Lesiecki08a</link>; <link linkend="Betts13a">Betts13a</link>; <link linkend="Knol13a">Knol13a</link>; <link linkend="Dagger">Dagger</link>]</simpara></footnote>.</simpara>
-<section xml:id="_syntax-14">
-<title>Syntax</title>
-<programlisting language="ebnf" linenumbering="unnumbered">BindingPattern <Yield>:
- ObjectBindingPattern<Yield>
- | ArrayBindingPattern<Yield>
-;
-
-ObjectBindingPattern <Yield> returns BindingPattern:
- {BindingPattern}
- '{' (properties+=BindingProperty<Yield,AllowType=false> (',' properties+=BindingProperty<Yield,AllowType=false>)*)? '}'
-;
-
-ArrayBindingPattern <Yield> returns BindingPattern:
- {BindingPattern}
- '['
- elements+=Elision* (
- elements+=BindingRestElement<Yield>
- (',' elements+=Elision* elements+=BindingRestElement<Yield>)*
- (',' elements+=Elision*)?
- )?
- ']'
-;
-
-BindingProperty <Yield, AllowType>:
- =>(LiteralBindingPropertyName<Yield> ':') value=BindingElement<Yield>
- | value=SingleNameBinding<Yield,AllowType>
-;
-
-fragment LiteralBindingPropertyName <Yield>*:
- declaredName=IdentifierName | declaredName=STRING | declaredName=NumericLiteralAsString
- // this is added here due to special treatment for a known set of expressions
- | '[' (declaredName=SymbolLiteralComputedName<Yield> | declaredName=STRING) ']'
-;</programlisting>
-</section>
-<section xml:id="_semantics-12">
-<title>Semantics</title>
-<simpara>The following example declares four variables <literal>a</literal>, <literal>b</literal>, <literal>x</literal>, and <literal>prop2</literal>. Variables <literal>a</literal> and <literal>x</literal> will have the value <literal>hello</literal>, whereas <literal>b</literal> and <literal>prop2</literal> will have value 42.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var [a,b] = ["hello", 42];
-
-var {prop1:x, prop2} = {prop1:"hello", prop2:42};</programlisting>
-<simpara>In the case of <literal>prop2</literal>, we do not provide a property name and variable name separately; this is useful in cases where the property name also makes for a
-suitable variable name (called <literal>single name binding</literal>).</simpara>
-<simpara>One of the most useful use cases of destructuring is in a <literal>for..of</literal> loop.
-Take this example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var arr1 = [ ["hello",1,2,3], ["goodbye",4,5,6] ];
-for(var [head,...tail] of arr1) {
- console.log(head,'/',tail);
-}
-// will print:
-// hello / [ 1, 2, 3 ]
-// goodbye / [ 4, 5, 6 ]
-
-var arr2 = [ {key:"hello", value:42}, {key:"goodbye", value:43} ];
-for(var {key,value} of arr2) {
- console.log(key,'/',value);
-}
-// will print:
-// hello / 42
-// goodbye / 43</programlisting>
-<simpara>Array and object destructuring pattern can appear in many different places:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>In a variable declaration (not just in variable statements but also in other places where variable declarations are allowed, e.g. plain for loops; called <emphasis>destructuring binding</emphasis>; see <xref linkend="_variable-statement"/>).</simpara>
-</listitem>
-<listitem>
-<simpara>On the left-hand side of an assignment expression (the assignment expression is then called <emphasis>destructuring assignment</emphasis>; see <xref linkend="_assignment-expression"/>).</simpara>
-</listitem>
-<listitem>
-<simpara>In a <literal>for..in</literal> or <literal>for..of</literal> loop on the left side of the <literal>in</literal>/<literal>of</literal> (see <xref linkend="_for-of-statement"/>).</simpara>
-<note>
-<simpara>It can also be used in plain statements, but then we actually have one of the above two use cases.</simpara>
-</note>
-</listitem>
-<listitem>
-<simpara>With lists of formal parameters or function arguments (not supported yet).</simpara>
-</listitem>
-</itemizedlist>
-<simpara>For further details on array and object destructuring please refer to the ECMAScript 6 specification - [<link linkend="ECMA15a">ECMA15a</link>].</simpara>
-<simpara>Type annotations can only be added when a new variable name is introduced since the short version would be ambiguous with the long one.
-For example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var {x: someTypeOrNewVar} = ol</programlisting>
-<simpara>could either mean that a new variable <literal>someTypeOrNewVar</literal> is declared and <literal>ol.x</literal> is assigned to it, or that a new variable <literal>x</literal> is declared with type <literal>someTypeOrNewVar</literal>.
-The longer form would look like this:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var {x: x: someType} = ol</programlisting>
-<simpara>We can make this more readable:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var {propOfOl: newVar: typeOfNewVar} = ol</programlisting>
-</section>
-</section>
-<section xml:id="_dependency-injection" role="language-n4js">
-<title>Dependency Injection</title>
-<simpara>This chapter describes <link linkend="_acronyms">DI</link> mechanisms for N4JS.
-This includes compiler, validation and language extensions that allow to achieve DI mechanisms built in into the N4JS language and IDE.</simpara>
-<simpara>N4JS <link linkend="_acronyms">DI</link> support specifies a means for obtaining objects in such a way as to maximize reusability, testability and maintainability,
-especially compared to traditional approaches such as constructors, factories and service locators.
-While this can be achieved manually (without tooling support) it is difficult for nontrivial applications.
-The solutions that DI provides should empower N4JS users to achieve the above goals without the burden of maintaining so-called ’boilerplate’ code.</simpara>
-<figure xml:id="fig-di-terms">
-<title>DI Basic Terms</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_extFeatures/fig/diBasicTerms.png" width="60%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>diBasicTerms</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara><emphasis>key: pass the dependency instead of letting the client create or find it</emphasis></simpara>
-<simpara>Core terms</simpara>
-<itemizedlist>
-<listitem>
-<simpara><emphasis role="strong">Service</emphasis> - A set of APIs describing the functionality of the service.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Service Implementation</emphasis>s - One or more implementations of given service API.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Client</emphasis> - Consumer of a given functionality, uses the given <emphasis role="strong">Service Implementation</emphasis>.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Injector</emphasis> - Object providing <emphasis role="strong">Service Implementation</emphasis> of a specific <emphasis role="strong">Service</emphasis>, according to configuration.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Binding</emphasis> - Part of configuration describing which interface implementing a subtype will be injected, when a given interface is requested.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Provider</emphasis> - Factory used to create instances of a given <emphasis role="strong">Service Implementation</emphasis> or its sub-components, can be a method.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">Injection Point</emphasis> - Part of the user’s code that will have the given dependency injected. This is usually fields, method parameters, constructor parameters etc.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">DI configuration</emphasis> - This describes which elements of the user’s code are used in mechanisms and how they are wired.
-It is derived from user code elements being marked with appropriate annotations, bindings and providers.</simpara>
-</listitem>
-<listitem>
-<simpara><emphasis role="strong">di wiring</emphasis> - The code responsible for creating user objects.
-These are injectors, type factories/providers, fields initiators etc.</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="_di-components-and-injectors">
-<title>DI Components and Injectors</title>
-<simpara>N4JS’ <xref linkend="_dependency-injection"/> systems is based on the notion of <link linkend="_acronyms">DIC</link>.</simpara>
-<definition>
-<title>DI Component</title>
-<simpara>
-<anchor xml:id="di_component" xreflabel="[di_component]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="di_component">DI Component</link></simpara>
-<simpara>
-
-A <link linkend="_acronyms">DIC</link> is a N4Class annotated with <literal>@GenerateInjector</literal>.</simpara>
-</definition>
-<simpara>This annotation causes an <emphasis>injector</emphasis> to be created for (and associated to) the <link linkend="_acronyms">DI</link>.
-DIC can be composed; meaning that when requested to inject an instance of a type, a DIC’s injector can delegate this request to the injector of the containing DIC.
-An injector always prioritizes its own configuration before delegating to the container’s injector.
-For validation purposes, a child DI can be annotated with <literal>@WithParent</literal> to ensure that it is always used with a proper parent.</simpara>
-<simpara><emphasis>Injector</emphasis> is the main object of DI mechanisms responsible for creating object graphs of the application.
-At runtime, injectors are instances of <literal>N4Injector</literal>.</simpara>
-<requirement xml:id="IDE-138">
-<title>DI Component and Injector</title>
-<simpara>
-<anchor xml:id="Req-IDE-138" xreflabel="[Req-IDE-138]"/>
-<emphasis role="strong">Requirement: IDE-138:</emphasis>
-<link linkend="Req-IDE-138">DI Component and Injector</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>The following constraints must hold for a class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> marked as DIC:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A subclass <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> is a DIC as well and it must be marked with <literal>GenerateInjector</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>If a parent <link linkend="_dicomponent-relations">DIC</link> <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> is specified via <literal>WithParent</literal>, then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> must be a DIC as well.</simpara>
-</listitem>
-<listitem>
-<simpara>The injector associated to a DIC is of type <literal>N4Injector</literal>. It can be retrieved via <literal>N4Injector.of(DIC)</literal> in which <literal>DIC</literal> is the <literal>DIC</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Injectors associated to DIC a are DI-singletons (cf. <xref linkend="_singleton-scope"/>).
-Two calls to <literal>N4Injector.of(DIC)</literal> are different (as different DIC are assumed).</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-139">
-<title>Injection Phase</title>
-<simpara>
-<anchor xml:id="Req-IDE-139" xreflabel="[Req-IDE-139]"/>
-<emphasis role="strong">Requirement: IDE-139:</emphasis>
-<link linkend="Req-IDE-139">Injection Phase</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>We call the (transitive) creation and setting of values by an injector <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi></math> caused by the creation of an root object <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>R</mi></math> the <emphasis>injection phase</emphasis>.
-If an instance <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> is newly created by the injector <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi></math> (regardless of the injection point being used), the injection is transitively applied on <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math>.
-The following constraints have to hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Root objects are created by one of the following mechanisms:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>Any class or interface can be created as root objects via an injector associated to a DIC:<?asciidoc-br?>
-<literal>var x: X = N4Injector.of(DIC).create(X);</literal><?asciidoc-br?>
-in which <literal>DIC</literal> is a DIC.</simpara>
-<simpara>Of course, an appropriate binding must exist. <footnote><simpara>Usually, only the <literal>DIC</literal> itself is created like that, e.g., <literal role="language-n4js">var dic = N4Injector.of(DIC).create(DIC);</literal></simpara></footnote></simpara>
-</listitem>
-<listitem>
-<simpara>If a type has the injector being injected, e.g. via field injection <literal>@Inject injector: N4Injector;</literal>, then this injector can be used anytime in the control flow to create
-a new root object similar as above (using <literal>create</literal> method).</simpara>
-</listitem>
-<listitem>
-<simpara>If a provider has been injected (i.e. an instance of <literal>{N4Provider}</literal>), then its <literal>get()</literal> method can be used to create a root object causing a new injection phase to take place.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> is marked as injection point, all its arguments are set by the injector.
-This is also true for an inherited constructor marked as an injection point.
-See <xref linkend="Req-IDE-143"/> . For all arguments the injection phase constraints have to hold as well.</simpara>
-</listitem>
-<listitem>
-<simpara>All fields of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math>, including <emphasis>inherited</emphasis> once, marked as injection points are set by the injector.
-For all fields the injection phase constraints have to hold as well.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The injector may use a provider method (of a binder) to create nested instances.</simpara>
-<simpara>The injector is configured with <emphasis>Binders</emphasis> and it tracks <emphasis>Bindings</emphasis> between types (<xref linkend="_binders-and-bindings"/>).
-An N4JS developer normally would not interact with this object directly except when defining an entry-point to his application.
-<emphasis>Injector</emphasis>s are configured with <emphasis>Binder</emphasis>s which contain explicit <emphasis>Binding</emphasis>s defined by an N4JS developer.
-A set of these combined with <emphasis>implicit bindings</emphasis> creates the <emphasis>di configuration</emphasis> used by a given injector.
-To configure given <emphasis>Injector</emphasis>s with given <emphasis>Binder</emphasis>(s) use <literal>@UseBinder</literal> annotation.</simpara>
-</requirement>
-<section xml:id="_dicomponent-relations">
-<title>DIComponent Relations</title>
-<simpara>A Parent-Child relation can be established between two DIComponents.
-Child DIComponents use the parent bindings but can also be configured with their own bindings or <emphasis>change</emphasis> targets used by a parent.
-The final circumstance is local to the child and is referred to as <emphasis>rebinding</emphasis>.
-For more information about bindings see <xref linkend="_binders-and-bindings"/>.
-A Child-Parent relation is expressed by the <literal>@WithParentInjector</literal> annotation attached to a given DIComponent.
-When this relation is defined between DIComponents, the user needs to take care to preserve the proper relation between injectors.
-In other words, the user must provide an instance of the parent injector (the injector of the DIComponent passes as a parameter to <literal>@WithParentInjector</literal>) when creating the child injector
-(injector of the DIComponent annotated with <literal>@WithParentInjector</literal>).</simpara>
-<example>
-<title>Simple DIComponents Relation</title>
-<programlisting language="n4js" linenumbering="unnumbered">@GenerateInjector
-class ParentDIComponent{}
-
-@GenerateInjector
-@WithParentInjector(ParentDIComponent)
-class ChildDIComponent{}
-
-var parentInejctor = N4Inejctor.of(ParentDiCompoennt);
-var childInjector = N4Inejctor.of(ChildDIComponent, parentInjector);</programlisting>
-</example>
-<simpara>With complex DIComponent structures, injector instances can be created with a directly-declared parent and also with any of its children.
-This is due to the fact that any child can rebind types, add new bindings, but not remove them.
-Any child is, therefore, <emphasis>compatible</emphasis> with its parents.</simpara>
-<definition>
-<title>Compatible DIComponent</title>
-<simpara>
-<anchor xml:id="compatible_dicomponent" xreflabel="[compatible_dicomponent]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="compatible_dicomponent">Compatible DIComponent</link></simpara>
-<simpara>
-
-A given DIComponent is compatible with another DIComponent if it has bindings for all keys in other component bindings.</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∃</mo><mi>D</mi><mi>I</mi><mi>C</mi><mn>1</mn><mo>,</mo><mi>D</mi><mi>I</mi><mi>C</mi><mn>2</mn><mi>:</mi><mi>D</mi><mi>I</mi><mi>C</mi><mn>1.</mn><mover accent="true"><mrow><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mi>i</mi><mi>n</mi><mi>g</mi></mrow><mo>¯</mo></mover><mo>.</mo><mover accent="true"><mrow><mi>k</mi><mi>e</mi><mi>y</mi></mrow><mo>¯</mo></mover><mo>⇒</mo><mi>D</mi><mi>I</mi><mi>C</mi><mn>2.</mn><mover accent="true"><mrow><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mi>i</mi><mi>n</mi><mi>g</mi></mrow><mo>¯</mo></mover><mo>.</mo><mover accent="true"><mrow><mi>k</mi><mi>e</mi><mi>y</mi></mrow><mo>¯</mo></mover><mo>⇔</mo><mi>D</mi><mi>I</mi><mi>C</mi><mn>2</mn><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>D</mi><mi>I</mi><mi>C</mi><mn>1</mn></math>
-<note>
-<simpara>Although subtype notation <math xmlns="http://www.w3.org/1998/Math/MathML"><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/></math> is used here it does <emphasis role="strong">not</emphasis> imply actual subtype relations.
-It was used in this instance for of lack of formal notations for DI concepts and because this is similar to the Liskov Substitution principle.</simpara>
-</note>
-<simpara>A complex Child-Parent relation between components is depicted in <xref linkend="fig-complex-dicomponents-relations"/> and <xref linkend="ex:complex-dicomponents-relations"/> below.</simpara>
-<figure xml:id="fig-complex-dicomponents-relations">
-<title>Complex DIComponents Relations</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_extFeatures/fig/diagDICParentChild.svg" width="50%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>diagDICParentChild</phrase></textobject>
-</mediaobject>
-</figure>
-</definition>
-<example xml:id="ex:complex-dicomponents-relations">
-<title>Complex DIComponents Relations</title>
-<programlisting language="n4js" linenumbering="unnumbered">@GenerateInjector class A {}
-@GenerateInjector @WithParentInjector(A) class B {}
-@GenerateInjector @WithParentInjector(B) class C {}
-@GenerateInjector @WithParentInjector(C) class D {}
-@GenerateInjector @WithParentInjector(A) class B2 {}
-@GenerateInjector @WithParentInjector(B2) class C2 {}
-@GenerateInjector @WithParentInjector(C2) class D2 {}
-@GenerateInjector @WithParentInjector(A) class X {}
-@GenerateInjector @WithParentInjector(C) class Y {}
-
-// creating injectors
-var injectorA = N4Injector.of(A);
-//following throws DIConfigurationError, expected parent is not provided
-//var injectorB = N4Injector.of(B);
-//correct declarations
-var injectorB = N4Injector.of(B, injectorA);
-var injectorC = N4Injector.of(C, injectorB);
-var injectorD = N4Injector.of(D, injectorC);
-var injectorB2 = N4Injector.of(B2, injectorA);
-var injectorC2 = N4Injector.of(C2, injectorB2);
-var injectorD2 = N4Injector.of(D2, injectorC2);
-
-//Any injector of {A,B,C,D,b2,C2,D2} s valid parent for injector of X, e.g. D or D2
-N4Injector.of(X, injectorD);//is ok as compatible parent is provided
-N4Injector.of(X, injectorD2);//is ok as compatible parent is provided
-
-N4Injector.of(Y, injectorC);//is ok as direct parent is provided
-N4Injector.of(Y, injectorD);//is ok as compatible parent is provided
-
-N4Injector.of(Y, injectorB2);//throws DIConfigurationError, incompatible parent is provided
-N4Injector.of(Y, injectorC2);//throws DIConfigurationError, incompatible parent is provided
-N4Injector.of(Y, injectorD2);//throws DIConfigurationError, incompatible parent is provided</programlisting>
-</example>
-</section>
-</section>
-<section xml:id="_binders-and-bindings">
-<title>Binders and Bindings</title>
-<simpara><emphasis>Binder</emphasis> allows an N4JS developer to (explicitly) define a set of <emphasis>Binding</emphasis>s that will be used by an <emphasis>Injector</emphasis> configured with a given <emphasis>Binder</emphasis>.
-There are two ways for <emphasis>Binder</emphasis> to define <emphasis>Binding</emphasis>s: <literal>@Bind</literal> (<xref linkend="_n4js-di-bind"/>) annotations and a method annotated with <literal>@Provides</literal>.</simpara>
-<simpara><emphasis>Binder</emphasis> is declared by annotating a class with the <literal>@Binder</literal> annotation.</simpara>
-<simpara>A <emphasis>Binding</emphasis> is part of a configuration that defines which instance of
-what type should be injected into an <emphasis>injection point</emphasis> (<xref linkend="_injection-points"/>) with an expected type.</simpara>
-<simpara><emphasis>Provider Method</emphasis> is essentially a <emphasis>factory method</emphasis> that is used to create an instance of a type.
-N4JS allows a developer to declare those methods (see <xref linkend="_n4js-di-provides"/>) which gives them a hook in instance creation process.
-Those methods will be used when creating instances by the <emphasis>Injector</emphasis> configured with the corresponding <emphasis>Binder</emphasis>.
-A provider method is a special kind of binding (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math>) in which the return type of the method is the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math>.
-The <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi></math> type is unknown at compile time (although it may be inferred by examining the return statements of the provide method).</simpara>
-<definition>
-<title>Binding</title>
-<simpara>
-<anchor xml:id="binding" xreflabel="[binding]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="binding">Binding</link></simpara>
-<simpara>
-
-A <emphasis>binding</emphasis> is a pair <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mrow><mi>k</mi><mi>e</mi><mi>y</mi></mrow><mrow><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi></mrow></mfenced></math>.
-It defines that for a dependency with a given key which usually is the expected type at the injection point.
-An instance of type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi></math> is injected.</simpara>
-<simpara>A <emphasis>binding</emphasis> is called <emphasis>explicit</emphasis> if it is declared in the code, i.e. via <literal>@Bind</literal>
-annotation or <literal>@Provides</literal> annotation).</simpara>
-<simpara>A <emphasis>binding</emphasis> is called <emphasis>implicit</emphasis> if it is not declared.
-An implicit binding can only be used if the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math> is a class and derived from the type at the injection point, i.e. the type of the field or parameter to be injected.
-In that case, the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi></math> equals the <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math>.</simpara>
-<simpara>A provider method <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math> (in the binder) defines a binding</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>b</mi><mi>i</mi><mi>n</mi><mi>d</mi><mfenced close=")" open="("><mrow><mi>M</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></mrow><mi>X</mi></mfenced></math>
-<simpara>(in which <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>X</mi></math> is an existential type with <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∃</mo><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi></math>).</simpara>
-<simpara>For simplification, we define:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mi>k</mi><mi>e</mi><mi>y</mi><mo>*</mo><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>,</mo></mtd><mtd><mstyle mathvariant="bold"><mtext>if target is provider method</mtext></mstyle></mtd></mtr><mtr><mtd><mi>k</mi><mi>e</mi><mi>y</mi><mo>,</mo></mtd><mtd><mstyle mathvariant="bold"><mtext>otherwise (key is a type reference)</mtext></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr></mtable></math>
-<simpara>and</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>*</mo><mo>=</mo><mfenced close="" open="{"><mtable><mtr><mtd><mi>X</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>n</mi><mi>T</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>,</mo></mtd><mtd><mstyle mathvariant="bold"><mtext>if target is provider method</mtext></mstyle></mtd></mtr><mtr><mtd><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>,</mo></mtd><mtd><mstyle mathvariant="bold"><mtext>otherwise (target is a type reference)</mtext></mstyle></mtd></mtr></mtable></mfenced></mtd></mtr></mtable></math>
-</definition>
-<requirement xml:id="IDE-140">
-<title>Bindings</title>
-<simpara>
-<anchor xml:id="Req-IDE-140" xreflabel="[Req-IDE-140]"/>
-<emphasis role="strong">Requirement: IDE-140:</emphasis>
-<link linkend="Req-IDE-140">Bindings</link> (ver. 1)</simpara>
- <simpara>
-
-For a given binding <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mo>=</mo><mfenced close=")" open="("><mrow><mi>k</mi><mi>e</mi><mi>y</mi></mrow><mrow><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi></mrow></mfenced></math>, the following constraints must hold: <footnote><simpara>Note that other frameworks may define other constraints, e.g., arbitrary keys.</simpara></footnote></simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math> must be either a class or an interface.</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi></math> must either be a class or a provider method.</simpara>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi></math> is implicit, then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math> must be a class.
-If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math> references a type <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>, then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>=</mo><mi>T</mi></math> – even if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math> is a use-site structural type.</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>k</mi><mi>e</mi><mi>y</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>*</mo></math> can be nominal, structural or field-structural types, either definition-site or use-site.
-The injector and binder needs to take the different structural reference into account at runtime!</simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><mi>t</mi><mo>*</mo><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>k</mi><mi>e</mi><mi>y</mi></math> must hold</simpara>
-</listitem>
-<listitem>
-<simpara>If during injection phase no binding for a given key is found, an <literal>DIUnsatisfiedBindingError</literal> is thrown.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-141">
-<title>Transitive Bindings</title>
-<simpara>
-<anchor xml:id="Req-IDE-141" xreflabel="[Req-IDE-141]"/>
-<emphasis role="strong">Requirement: IDE-141:</emphasis>
-<link linkend="Req-IDE-141">Transitive Bindings</link> (ver. 1)</simpara>
- <simpara>
-
-If an injector contains two given bindings <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>1</mn></msub><mo>=</mo><mfenced close=")" open="("><mrow><mi>k</mi><mi>e</mi><msub><mi>y</mi><mn>1</mn></msub></mrow><mrow><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><msub><mi>t</mi><mn>1</mn></msub></mrow></mfenced></math> and
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>2</mn></msub><mo>=</mo><mfenced close=")" open="("><mrow><mi>k</mi><mi>e</mi><msub><mi>y</mi><mn>2</mn></msub></mrow><mrow><mi>k</mi><mi>e</mi><msub><mi>y</mi><mn>1</mn></msub></mrow></mfenced></math>, an effective binding
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>b</mi><mo>=</mo><mfenced close=")" open="("><mrow><mi>k</mi><mi>e</mi><msub><mi>y</mi><mn>2</mn></msub></mrow><mrow><mi>t</mi><mi>a</mi><mi>r</mi><mi>g</mi><mi>e</mi><msub><mi>t</mi><mn>1</mn></msub></mrow></mfenced></math> is derived (replacing
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>b</mi><mn>1</mn></msub></math>).</simpara>
-<simpara>N4JS <link linkend="_acronyms">DI</link> mechanisms don’t allow for injection of primitives or built-in types.
-Only user-defined N4Types can be used. In cases where a user needs to inject a primitive or a built-in type, the developer must wrap it into its own
-class <footnote><simpara>Cf. a blog post about micro types - <link xl:href="http://www.markhneedham.com/blog/2009/03/10/oo-micro-types/">http://www.markhneedham.com/blog/2009/03/10/oo-micro-types/</link>, and tiny types - <link xl:href="http://darrenhobbs.com/2007/04/11/tiny-types/">http://darrenhobbs.com/2007/04/11/tiny-types/</link></simpara></footnote>.
-This is to say that none of the following metatypes can be bound: primitive types, enumerations, functions, object types, union- or intersection types. It is possible to (implicitly) bind to built-in classes.</simpara>
-<simpara>While direct binding overriding or rebinding is not allowed, <emphasis>Injector</emphasis> can be configured in a way where one type can be separately bound to different types with implicit binding,
-<emphasis>explicit binding</emphasis> and in bindings of the child injectors.
-<emphasis>Binding precedence</emphasis> is a mechanism of <emphasis>Injector</emphasis> selecting a binding use for a type.
-It operates in the following order:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Try to use explicit binding, if this is not available:</simpara>
-</listitem>
-<listitem>
-<simpara>Try to delegate to parent injectors (order of lookup is not guaranteed, first found is selected). If this is not available then:</simpara>
-</listitem>
-<listitem>
-<simpara>Try to use use implicit binding, which is simply to attempt to create the instance.</simpara>
-</listitem>
-</orderedlist>
-<simpara>If no binding for a requested type is available an error will be thrown.</simpara>
-</requirement>
-</section>
-<section xml:id="_injection-points">
-<title>Injection Points</title>
-<simpara>By <emphasis>injection point</emphasis> we mean a place in the source code which, at runtime, will be expected to hold a reference to a particular type instance.</simpara>
-<section xml:id="_field-injection">
-<title>Field Injection</title>
-<simpara>In its simplest form, this is a class field annotated with <literal>@Inject</literal> annotation.
-At runtime, an instance of the containing class will be expected to hold reference to an instance of the field declared type.
-Usually that case
-is called <emphasis>Field Injection</emphasis>.</simpara>
-<requirement xml:id="IDE-142">
-<title>Field Injection</title>
-<simpara>
-<anchor xml:id="Req-IDE-142" xreflabel="[Req-IDE-142]"/>
-<emphasis role="strong">Requirement: IDE-142:</emphasis>
-<link linkend="Req-IDE-142">Field Injection</link> (ver. 1)</simpara>
- <simpara>
-
-The injector will inject the
-following fields:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>All directly contained fields annotated with <literal>@Inject</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>All inherited fields annotated with <literal>@Inject</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>The injected fields will be created by the injector and their fields will be injected as well.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<example>
-<title>Simple Field Injection</title>
-<simpara><xref linkend="ex:field-injection"/> demonstrates simple field injection using default bindings.
-Note that all inherited fields (i.e. <literal>A.xInA</literal>) are injected and also fields in injected fields (i.e. <literal>x.y</literal>)</simpara>
-<formalpara xml:id="ex:field-injection">
-<title>Simple Field Injection</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">class X {
- @Inject y: Y;
-}
-class Y {}
-
-class A {
- @Inject xInA: X;
-}
-class B extends A {
- @Inject xInB: X;
-}
-
-@GenerateInjector
-export public class DIC {
- @Inject a: B;
-}
-
-var dic = N4Injector.of(DIC).create(DIC);
-console.log(dic); // --> DIC
-console.log(dic.a); // --> B
-console.log(dic.a.xInA); // --> X
-console.log(dic.a.xInA.y); // --> Y
-console.log(dic.a.xInB); // --> X
-console.log(dic.a.xInB.y); // --> Y</programlisting>
-</para>
-</formalpara>
-</example>
-</section>
-<section xml:id="_constructor-injection">
-<title>Constructor Injection</title>
-<simpara>Parameters of the constructor can also be injected, in which case this is usually referred to as <emphasis>Constructor Inejction</emphasis>.
-This is similar to <emphasis>Method Injection</emphasis> and while constructor injection is supported in N4JS, method injection is not (see remarks below).</simpara>
-<simpara>When a constructor is annotated with <literal>@Inject</literal> annotation, all user-defined, non-generic types given as the parameters will be injected into the instance’s constructor created by the dependency injection framework.
-Currently, optional constructor parameters are always initialized and created by the framework, therefore, they are ensured to be available at the constructor invocation time.
-Unlike optional parameters, variadic parameters cannot be injected into a type’s constructor.
-In case of annotating a constructor with <literal>@Inject</literal> that has variadic parameters, a validation error will be reported.
-When a class’s constructor is annotated with <literal>@Inject</literal> annotation, it is highly recommended to annotate all explicitly-defined constructors at the subclass level.
-If this is not done, the injection chain can break and runtime errors might occur due to undefined constructor parameters.
-In the case of a possible broken injection chain due to missing <literal>@Inject</literal> annotations for any subclasses, a validation warning will
-be reported.</simpara>
-<requirement xml:id="IDE-143">
-<title>Constructor Injection</title>
-<simpara>
-<anchor xml:id="Req-IDE-143" xreflabel="[Req-IDE-143]"/>
-<emphasis role="strong">Requirement: IDE-143:</emphasis>
-<link linkend="Req-IDE-143">Constructor Injection</link> (ver. 1)</simpara>
- <simpara>
-
-If a class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> has a constructor marked as injection point, the
-following applies:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> is subclassed by <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math>, and if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> has no explicit constructor, then <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> inherits the constructor from <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi></math> and it will be an injection point handled by the injector during injection phase.</simpara>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi></math> provides its own injector, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> is no longer recognized by the injector during the injection phase.
-There will be a warning generated in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> to mark it as injection point as well in order to prevent inconsistent injection behavior.
-Still, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> must be called in <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>S</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math> similarly to other overridden constructors.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="_method-injection">
-<title>Method Injection</title>
-<simpara>Other kinds of injector points are method parameters where (usually) all method parameters are injected when the method is called.
-In a way, constructor injection is a special case of the method itself.</simpara>
-<section xml:id="_provider">
-<title>Provider</title>
-<simpara><emphasis>Provider</emphasis> is essentially a <emphasis>factory</emphasis> for a given type.
-By injecting an <literal>N4Provider</literal> into any injection point, one can acquire new instances of a given type provided by the injected provider.
-The providers prove useful when one has to solve re-injection issues since the depended type can be wired and injected via the provider rather than the dependency itself and can therefore obtain
-new instances from it if required.
-Provider can be also used as a means of delaying the instantiation time of a given type.</simpara>
-<simpara><literal>N4Provider</literal> is a public generic built-in interface that is used to support the re-injection.
-The generic type represents the dependent type that has to be obtained.
-The <literal>N4Provider</literal> interface has one single public method: <literal>public T get()</literal> which should be invoked from the client code when a new instance of the dependent type is required.
-Unlike any other unbound interfaces, the <literal>N4Provider</literal> can be injected without any explicit binding.</simpara>
-<simpara>The following snippet demonstrates the usage of <literal>N4Provider</literal>:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class SomeService { }
-
-@Singleton
-class SomeSingletonService { }
-
-class SomeClass {
-
- @Inject serviceProvider: N4Provider<SomeService>;
- @Inject singletonServiceProvider: N4Provider<SomeSingletonService>;
-
- void foo() {
- console.log(serviceProvider.get() ===
- serviceProvider.get()); //false
-
- console.log(singletonServiceProvider.get() ===
- singletonServiceProvider.get()); //true
- }
-
-}</programlisting>
-<simpara>It is important to note that the <literal>N4Provider</literal> interface can be extended by any user-defined interfaces and/or can be implemented by any user-defined classes.
-For those user-defined providers, consider all binding-related rules; the extended interface, for example, must be explicitly bound via a binder to be injected.
-The binding can be omitted only for the built-in <literal>N4Provider</literal>s.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_n4js-di-life-cycle-and-scopes">
-<title>N4JS DI Life Cycle and Scopes</title>
-<simpara><link linkend="_acronyms">DI</link> Life Cycle defines when a new instance is created by the injector as its destruction is handled by JavaScript.
-The creation depends on the scope of the type.
-Aside from the scopes, note that it is also possible to implement custom scopes and life cycle management via <literal>N4JSProvider</literal> and <literal>Binder@Provides</literal> methods.</simpara>
-<section xml:id="_injection-cylces">
-<title>Injection Cylces</title>
-<definition>
-<title>Injection Cycle</title>
-<simpara>
-<anchor xml:id="injection_cycle" xreflabel="[injection_cycle]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="injection_cycle">Injection Cycle</link></simpara>
-<simpara>
-
-We define an injection graph <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi><mfenced close=")" open="("><mi>V</mi><mi>E</mi></mfenced></math> as a directed graph as follows: <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>V</mi></math> (the vertices) is the set types of which instances are created during the injection phase and which use .
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>E</mi></math> (the edges) is a set of directed and labeled edges <math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close=")" open="("><msub><mi>v</mi><mn>1</mn></msub><msub><mi>v</mi><mn>2</mn></msub><mrow><mi>l</mi><mi>a</mi><mi>b</mi><mi>e</mi><mi>l</mi></mrow></mfenced></math>, where label indicates the injection point:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close=")" open="("><msub><mi>T</mi><mi>o</mi></msub><msub><mi>T</mi><mi>f</mi></msub><mrow><mi>"</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mi>"</mi></mrow></mfenced></math>, if <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mi>f</mi></msub></math> is the actualy type of an an injected field of an instance of type <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mi>o</mi></msub></math></simpara>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mfenced close=")" open="("><msub><mi>T</mi><mi>c</mi></msub><msub><mi>T</mi><mi>p</mi></msub><mrow><mi>"</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mi>"</mi></mrow></mfenced></math>, if <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mi>p</mi></msub></math> is the type of a parameter used in a constructor injection of type <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>T</mi><mi>c</mi></msub></math></simpara>
-</listitem>
-</orderedlist>
-<simpara>One cycle in this graph is an injection cycle.</simpara>
-</definition>
-<simpara>When injecting instances into an object, cycles have to be detected and handled independently from the scope.
-If this is not done, the following examples would result in an infinite loop causing the entire script to freeze until the engine reports an error:</simpara>
-<informaltable frame="none" rowsep="1" colsep="0">
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="57.1428*"/>
-<colspec colname="col_2" colwidth="42.8572*"/>
-<tbody>
-<row>
-<entry align="left" valign="bottom"><programlisting language="n4js" linenumbering="unnumbered">class A { @Inject b: B; }
-class B { @Inject a: A; }</programlisting></entry>
-<entry align="center" valign="top"><figure xml:id="fig-field-cycle">
-<title>Field Cycle</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_extFeatures/fig/injectionGraph_cycleField.svg" width="40%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>injectionGraph cycleField</phrase></textobject>
-</mediaobject>
-</figure></entry>
-</row>
-<row>
-<entry align="left" valign="bottom"><programlisting language="n4js" linenumbering="unnumbered">class C { @Inject constructor(d: D) {} }
-class D { @Inject c: C; }</programlisting></entry>
-<entry align="center" valign="top"><figure xml:id="fig-ctor-field">
-<title>Ctor Field Cycle</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_extFeatures/fig/injectionGraph_cycleCtorField.svg" width="40%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>injectionGraph cycleCtorField</phrase></textobject>
-</mediaobject>
-</figure></entry>
-</row>
-<row>
-<entry align="left" valign="bottom"><programlisting language="n4js" linenumbering="unnumbered">class E { @Inject constructor(f: F) {} }
-class F { @Inject constructor(e: E) {} }</programlisting></entry>
-<entry align="center" valign="top"><figure xml:id="fig-ctor-cycle">
-<title>Ctor Cycle</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/11_extFeatures/fig/injectionGraph_cycleCtor.svg" width="40%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>injectionGraph cycleCtor</phrase></textobject>
-</mediaobject>
-</figure></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>The injector needs to detect these cycles and resolve them.</simpara>
-<requirement xml:id="IDE-144">
-<title>Resolution of Injection Cycles</title>
-<simpara>
-<anchor xml:id="Req-IDE-144" xreflabel="[Req-IDE-144]"/>
-<emphasis role="strong">Requirement: IDE-144:</emphasis>
-<link linkend="Req-IDE-144">Resolution of Injection Cycles</link> (ver. 1)</simpara>
- <simpara>
-
-A cycle <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi><mo>⊂</mo><mi>G</mi></math>, with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi></math> being an injection graph, is resolved as follows:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi></math> contains no edge with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>l</mi><mi>a</mi><mi>b</mi><mi>e</mi><mi>l</mi><mo>=</mo><mi>"</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mi>"</mi></math>, the cycle is resolved using the algorithm described below.</simpara>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>c</mi></math> contains at least one edge with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>l</mi><mi>a</mi><mi>b</mi><mi>e</mi><mi>l</mi><mo>=</mo><mi>"</mi><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi><mi>"</mi></math>, a runtime exception is thrown.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<simpara>Cycles stemming from field injection are resolved by halting the creation of new instances of types which have been already created by a containing instance.
-The previously-created instance is then reused.
-This makes injecting the instance of a (transitive) container less complicated and without the need to pass the container instance down the entire chain.
-The following pseudo code describes the algorithm to create new instances which are injected into a newly created object:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">function injectDependencies(object) {
- doInjectionWithCylceAwareness(object, {(typeof object -> object)})
-}
-
-function doInjectionWithCylceAwareness(object, createdInstancesPerType) {
- forall v $\in$ injectedVars of object {
- var type = retrieveBoundType(v)
- var instance = createdInstancesPerType.get(type)
- if (not exists instance) {
- instance = createInstance(type, createdInstancesPerType)
- doInjectionWithCylceAwareness(instance,
- createdInstancesPerType $\cap$ {(type->instance)})
- }
- v.value = instance;
- }
-}</programlisting>
-<simpara>The actual instance is created in line 10 via <literal>createInstance</literal>.
-This function then takes scopes into account.
-The <literal>createdInstancesPerType</literal> map is passed to that function in order to enable cycle detection for constructor injection.
-The following scopes are supported by the N4JS DI, other scopes, cf. <link xl:href="https://jersey.java.net/documentation/latest/ioc.html">Jersey custom scopes</link> and <link xl:href="https://github.com/google/guice/wiki/CustomScopes">Guice custom scopes</link>, may be added in the future.</simpara>
-<simpara>This algorithm is not working for constructor injection because it is possible to already access all fields of the arguments passed to the constructor.
-In the algorithm, however, the instances may not be completely initialized.</simpara>
-</section>
-<section xml:id="_default-scope">
-<title>Default Scope</title>
-<simpara>The default scope always creates a new instance.</simpara>
-</section>
-<section xml:id="_singleton-scope">
-<title>Singleton Scope</title>
-<simpara>The singleton scope (per injector) creates one instance (of the type with <literal>@Singleton</literal> scope) per injector, which is then shared between clients.</simpara>
-<simpara>The injector will preserve a single instance of the type of <literal>S</literal> and will provide it to all injection points where type of <literal>S</literal> is used.
-Assuming nested injectors without any declared binding where the second parameter is <literal>S</literal>, the same preserved singleton instance will be available for all nested injectors at all injection points as well.</simpara>
-<simpara>The singleton preservation behavior changes when explicit bindings are declared for type <literal>S</literal> on the nested injector level.
-Let’s assume that the type <literal>S</literal> exists and the type is annotated with <literal>@Singleton</literal>.
-Furthermore, there is a declared binding where the binding’s second argument is <literal>S</literal>.
-In that case, unlike in other dependency injection frameworks, nested injectors may preserve a singleton for itself and all descendant injectors with <literal>@Bind</literal> annotation.
-In this case, the preserved singleton at the child injector level will be a different instance than the one at the parent injectors.</simpara>
-<simpara>The tables below depict the expected runtime behavior of singletons used at different injector levels.
-Assume the following are injectors: <literal>C</literal>, <literal>D</literal>, <literal>E</literal>, <literal>F</literal> and <literal>G</literal>. Injector <literal>C</literal> is the top most injector and its nesting injector <literal>D</literal>, hence injector <literal>C</literal> is the parent of the injector <literal>D</literal>.
-Injector <literal>D</literal> is nesting <literal>E</literal> and so on.
-The most nested injector is <literal>G</literal>. Let’s assume <literal>J</literal> is an interface, class <literal>U</literal> implements interface <literal>J</literal> and class <literal>V</literal> extends class <literal>U</literal>.
-Finally assume both <literal>U</literal> and <literal>V</literal> are annotated with <literal>@Singleton</literal> at definition-site.</simpara>
-<simpara><xref linkend="tab:diNoBindings"/> depicts the singleton preservation for nested injectors without any bindings.
-All injectors use the same instance from a type.
-Type <literal>J</literal> is not available at all since it is not bound to any concrete implementation:</simpara>
-<table xml:id="tab:diNoBindings" frame="all" rowsep="1" colsep="1">
-<title>DI No Bindings</title>
-<tgroup cols="6">
-<colspec colname="col_1" colwidth="28.5714*"/>
-<colspec colname="col_2" colwidth="14.2857*"/>
-<colspec colname="col_3" colwidth="14.2857*"/>
-<colspec colname="col_4" colwidth="14.2857*"/>
-<colspec colname="col_5" colwidth="14.2857*"/>
-<colspec colname="col_6" colwidth="14.2858*"/>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Binding</emphasis></simpara></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Injector nesting (<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>></mo></math>)</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>C</simpara></entry>
-<entry align="center" valign="top"><simpara>D</simpara></entry>
-<entry align="center" valign="top"><simpara>E</simpara></entry>
-<entry align="center" valign="top"><simpara>F</simpara></entry>
-<entry align="center" valign="top"><simpara>G</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">J</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>N</mi><mi>a</mi><mi>N</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>N</mi><mi>a</mi><mi>N</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>N</mi><mi>a</mi><mi>N</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>N</mi><mi>a</mi><mi>N</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>N</mi><mi>a</mi><mi>N</mi></math></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">U</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">V</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara><xref linkend="tab:diTransitiveBindings"/> is configured by explicit bindings. At the root injector level, type <literal>J</literal> is bound to type <literal>U</literal>.
-Since the second argument of the binding is declared as a singleton at the definition-site,
-this explicit binding implicitly ensures that the injector and all of its descendants preserve a singleton of the bound type <literal>U</literal>.
-At injector level <literal>C</literal>, <literal>D</literal> and <literal>E</literal>, the same instance is used for type <literal>J</literal> which is type <literal>U</literal> at runtime.
-At injector level <literal>E</literal> there is an additional binding from type <literal>U</literal> to type <literal>V</literal> that overrules the binding declared at the root injector level.
-With this binding, each places where <literal>J</literal> is declared, type <literal>U</literal> is used at runtime.</simpara>
-<simpara>Furthermore, since <literal>V</literal> is declared as a singleton, both injector <literal>F</literal> and <literal>G</literal> are using a shared singleton instance of type <literal>V</literal>.
-Finally, for type <literal>V</literal>, injector <literal>C</literal>, <literal>D</literal> and <literal>E</literal> should use a separate instance of <literal>V</literal> other than injector level <literal>F</literal> and <literal>G</literal> because <literal>V</literal> is preserved at injector level <literal>F</literal> with the <literal>U</literal> <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>→</mo></math> <literal>V</literal> binding.</simpara>
-<table xml:id="tab:diTransitiveBindings" frame="all" rowsep="1" colsep="1">
-<title>DI Transitive Bindings</title>
-<tgroup cols="6">
-<colspec colname="col_1" colwidth="28.5714*"/>
-<colspec colname="col_2" colwidth="14.2857*"/>
-<colspec colname="col_3" colwidth="14.2857*"/>
-<colspec colname="col_4" colwidth="14.2857*"/>
-<colspec colname="col_5" colwidth="14.2857*"/>
-<colspec colname="col_6" colwidth="14.2858*"/>
-<thead>
-<row>
-<entry align="center" valign="top">Binding</entry>
-<entry align="center" valign="top">J → U</entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top">U → V</entry>
-<entry align="center" valign="top"></entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Injector nesting (>)</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>C</simpara></entry>
-<entry align="center" valign="top"><simpara>D</simpara></entry>
-<entry align="center" valign="top"><simpara>E</simpara></entry>
-<entry align="center" valign="top"><simpara>F</simpara></entry>
-<entry align="center" valign="top"><simpara>G</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">J</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">U</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">V</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>1</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>1</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>1</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara><xref linkend="tab:diReBinding"/> depicts the singleton behaviour but unlike the above
-table, the bindings are declared for the interface <literal>J</literal>.</simpara>
-<table xml:id="tab:diReBinding" frame="all" rowsep="1" colsep="1">
-<title>DI Re - Binding</title>
-<tgroup cols="6">
-<colspec colname="col_1" colwidth="28.5714*"/>
-<colspec colname="col_2" colwidth="14.2857*"/>
-<colspec colname="col_3" colwidth="14.2857*"/>
-<colspec colname="col_4" colwidth="14.2857*"/>
-<colspec colname="col_5" colwidth="14.2857*"/>
-<colspec colname="col_6" colwidth="14.2858*"/>
-<thead>
-<row>
-<entry align="center" valign="top">Binding</entry>
-<entry align="center" valign="top">J → U</entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top">J → V</entry>
-<entry align="center" valign="top"></entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Injector nesting (<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>></mo></math>)</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>C</simpara></entry>
-<entry align="center" valign="top"><simpara>D</simpara></entry>
-<entry align="center" valign="top"><simpara>E</simpara></entry>
-<entry align="center" valign="top"><simpara>F</simpara></entry>
-<entry align="center" valign="top"><simpara>G</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">J</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">U</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">V</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>1</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>1</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>1</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-<simpara><xref linkend="tab:diChildBinding"/> describes the singleton behavior when both bindings are configured at child injector levels but not the root injector level.</simpara>
-<table xml:id="tab:diChildBinding" frame="all" rowsep="1" colsep="1">
-<title>DI Child Binding</title>
-<tgroup cols="6">
-<colspec colname="col_1" colwidth="28.5714*"/>
-<colspec colname="col_2" colwidth="14.2857*"/>
-<colspec colname="col_3" colwidth="14.2857*"/>
-<colspec colname="col_4" colwidth="14.2857*"/>
-<colspec colname="col_5" colwidth="14.2857*"/>
-<colspec colname="col_6" colwidth="14.2858*"/>
-<thead>
-<row>
-<entry align="center" valign="top">Binding</entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top">U <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>→</mo></math> V</entry>
-<entry align="center" valign="top"></entry>
-<entry align="center" valign="top">J <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>→</mo></math> U</entry>
-<entry align="center" valign="top"></entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">Injector nesting (<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>></mo></math>)</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara>C</simpara></entry>
-<entry align="center" valign="top"><simpara>D</simpara></entry>
-<entry align="center" valign="top"><simpara>E</simpara></entry>
-<entry align="center" valign="top"><simpara>F</simpara></entry>
-<entry align="center" valign="top"><simpara>G</simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">J</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>N</mi><mi>a</mi><mi>N</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>N</mi><mi>a</mi><mi>N</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>N</mi><mi>a</mi><mi>N</mi></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">U</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>1</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>U</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><emphasis role="strong">V</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>1</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-<entry align="center" valign="top"><simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>V</mi><mn>0</mn></msub></math></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</table>
-</section>
-<section xml:id="_per-injection-chain-singleton">
-<title>Per Injection Chain Singleton</title>
-<simpara>The per injection chain singleton is ’between’ the default and singleton scope.
-It can be used in order to explicitly describe the situation which happens when a simple cycle is resolved automatically.
-It has more effects that lead to a more deterministic behavior.</simpara>
-<simpara>Assume a provider declared as</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">var pb: Provider<B>;</programlisting>
-<simpara>to be available:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">@PerInjectionSingleton
-class A { }
-
-class B { @Inject a: A; @Inject a1: A;}
-
-b1=pb.get();
-b2=pb.get();
-b1.a != b2.a
-b1.a == b1.a1
-b2.a == b2.a1</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">@Singleton
-class A { }
-
-class B { @Inject a: A; @Inject a1: A;}
-
-b1=pb.get();
-b2=pb.get();
-b1.a == b2.a
-b1.a == b1.a1
-b2.a == b2.a1</programlisting>
-<programlisting language="n4js" linenumbering="unnumbered">// no annotation
-class A { }
-
-class B { @Inject a A; @Inject a1: A;}
-
-b1=pb.get();
-b2=pb.get();
-b1.a != b2.a
-b1.a != b1.a1
-b2.a != b2.a1</programlisting>
-</section>
-</section>
-<section xml:id="_validation-of-callsites-targeting-n4injector-methods">
-<title>Validation of callsites targeting N4Injector methods</title>
-<simpara>Terminology for this section:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>a value is <emphasis role="strong">injectable</emphasis> if it</simpara>
-<itemizedlist>
-<listitem>
-<simpara>either conforms to a user-defined class or interface (a non-parameterized one, that is),</simpara>
-</listitem>
-<listitem>
-<simpara>or conforms to Provider-of-T where T is injectable itself.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>a classifier declaring injected members is said to <emphasis role="strong">require injection</emphasis></simpara>
-</listitem>
-</itemizedlist>
-<simpara>To better understand the validations in effect for callsites targeting</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">N4Injector.of(ctorOfDIC: constructor{N4Object}, parentDIC: N4Injector?, ...providedBinders: N4Object)</programlisting>
-<simpara>we can recap that at runtime:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The first argument denotes a DIC constructor.</simpara>
-</listitem>
-<listitem>
-<simpara>The second (optional) argument is an injector.</simpara>
-</listitem>
-<listitem>
-<simpara>Lastly, the purpose of <literal>providedBinders</literal> is as follows:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The DIC above is marked with one or more <literal>@UseBinder</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Some of those binders may require injection.</simpara>
-</listitem>
-<listitem>
-<simpara>Some of those binders may have constructor(s) taking parameters.</simpara>
-</listitem>
-<listitem>
-<simpara>The set of binders described above should match the providedBinders.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-<simpara>Validations in effect for <literal>N4Injector.create(type{T} ctor)</literal> callsites:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>type{T}</literal> should be injectable (in particular, it may be an <literal>N4Provider</literal>).</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_n4js-di-annotations">
-<title>N4JS DI Annotations</title>
-<simpara>Following annotations describe API used to configure N4JSDI.</simpara>
-<section xml:id="_n4js-di-generateinjector">
-<title>N4JS DI @GenerateInjector</title>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>name</term>
-<listitem>
-<simpara>@GenerateInjector</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>targets</term>
-<listitem>
-<simpara>N4Class</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>retention policy</term>
-<listitem>
-<simpara>RUNTIME</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>transitive</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>repeatable</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><literal>@GenerateInjector</literal> marks a given class as DIComponent of the graph.
-The generated injector will be responsible for creating an instance of that class and all of its dependencies.</simpara>
-</section>
-<section xml:id="_n4js-di-withparentinjector">
-<title>N4JS DI @WithParentInjector</title>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>name</term>
-<listitem>
-<simpara>@WithParentInjector</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>targets</term>
-<listitem>
-<simpara>N4Class</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>retention policy</term>
-<listitem>
-<simpara>RUNTIME</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>transitive</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>repeatable</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments</term>
-<listitem>
-<simpara>TypeRef</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><literal>@WithParentInjector</literal> marks given <emphasis>injector</emphasis> as depended on other <emphasis>injector</emphasis>.
-The depended <emphasis>injector</emphasis> may use provided <emphasis>injector</emphasis> to create instances of objects required in its object graph.</simpara>
-<simpara>Additional <emphasis>WithParentInjector</emphasis> constraints:</simpara>
-<requirement xml:id="IDE-145">
-<title>DI WithParentInjector</title>
-<simpara>
-<anchor xml:id="Req-IDE-145" xreflabel="[Req-IDE-145]"/>
-<emphasis role="strong">Requirement: IDE-145:</emphasis>
-<link linkend="Req-IDE-145">DI WithParentInjector</link> (ver. 1)</simpara>
- <simpara>
-
-1. Allowed only on <literal>N4ClassDeclarations</literal> annotated with <literal>@GenerateInjector</literal>.
-2. Its parameter can only be <literal>N4ClassDeclarations</literal> annotated with .</simpara>
-</requirement>
-</section>
-<section xml:id="_n4js-di-usebinder">
-<title>N4JS DI @UseBinder</title>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>name</term>
-<listitem>
-<simpara>@UseBinder</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>targets</term>
-<listitem>
-<simpara>N4Class</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>retention policy</term>
-<listitem>
-<simpara>RUNTIME</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>transitive</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments</term>
-<listitem>
-<simpara>TypeRef</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments are optional</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><literal>@UseBinder</literal> describes <emphasis>Binder</emphasis> to be used (configure) target <emphasis>Injector</emphasis>.</simpara>
-<requirement xml:id="IDE-146">
-<title>DI UseInjector</title>
-<simpara>
-<anchor xml:id="Req-IDE-146" xreflabel="[Req-IDE-146]"/>
-<emphasis role="strong">Requirement: IDE-146:</emphasis>
-<link linkend="Req-IDE-146">DI UseInjector</link> (ver. 1)</simpara>
- <simpara>
-
-1. Allowed only on <literal>N4ClassDeclarations</literal> annotated with <literal>@GenerateInjector</literal>.
-2. Its parameter can only be <literal>N4ClassDeclarations</literal> annotated with <literal>@Binder</literal>.</simpara>
-</requirement>
-</section>
-<section xml:id="_n4js-di-binder">
-<title>N4JS DI @Binder</title>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>name</term>
-<listitem>
-<simpara>@Binder</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>targets</term>
-<listitem>
-<simpara>N4Class</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>retention policy</term>
-<listitem>
-<simpara>RUNTIME</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>transitive</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>repeatable</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments</term>
-<listitem>
-<simpara>NONE</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><literal>@Binder</literal> defines a list of bind configurations.
-That can be either <literal>@Bind</literal> annotations on <literal>@Binder</literal> itself or its factory methods annotated with <literal>@Provides</literal>.</simpara>
-<requirement xml:id="IDE-147">
-<title>DI binder</title>
-<simpara>
-<anchor xml:id="Req-IDE-147" xreflabel="[Req-IDE-147]"/>
-<emphasis role="strong">Requirement: IDE-147:</emphasis>
-<link linkend="Req-IDE-147">DI binder</link> (ver. 1)</simpara>
- <simpara>
-
-1. Target <literal>N4ClassDeclaration</literal> must not be <emphasis>abstract</emphasis>.
-2. Target <literal>N4ClassDeclaration</literal> must not be annotated with <literal>@GenerateInjector</literal>.
-3. Target class cannot have <emphasis>injection points</emphasis>.</simpara>
-</requirement>
-</section>
-<section xml:id="_n4js-di-bind">
-<title>N4JS DI @Bind</title>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>name</term>
-<listitem>
-<simpara>@Bind</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>targets</term>
-<listitem>
-<simpara>N4ClassDeclaration</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>retention policy</term>
-<listitem>
-<simpara>RUNTIME</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>transitive</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments</term>
-<listitem>
-<simpara>TypeRef key, TypeRef target</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments are optional</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>Defines <emphasis>binding</emphasis> between type and subtype that will be used by injector when configured with target <xref linkend="_n4js-di-binder"/>.
-See also <xref linkend="_validation-of-callsites-targeting-n4injector-methods"/> for description of injectable types.</simpara>
-<requirement xml:id="IDE-148">
-<title>DI Bind</title>
-<simpara>
-<anchor xml:id="Req-IDE-148" xreflabel="[Req-IDE-148]"/>
-<emphasis role="strong">Requirement: IDE-148:</emphasis>
-<link linkend="Req-IDE-148">DI Bind</link> (ver. 1)</simpara>
- <simpara>
-
-1. Allowed only on <literal>N4ClassDeclarations</literal> that are annotated with <literal>@Binder</literal>(<xref linkend="_n4js-di-binder"/>).
-2. Parameters are instances of one of the values described in <xref linkend="_validation-of-callsites-targeting-n4injector-methods"/>.
-3. The second parameter must be a subtype of the first one.</simpara>
-</requirement>
-</section>
-<section xml:id="_n4js-di-provides">
-<title>N4JS DI @Provides</title>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>name</term>
-<listitem>
-<simpara>@Provides</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>targets</term>
-<listitem>
-<simpara>N4MethodDeclaration</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>retention policy</term>
-<listitem>
-<simpara>RUNTIME</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>transitive</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>repeatable</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments</term>
-<listitem>
-<simpara>NONE</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><literal>@Provides</literal> marks <emphasis>factory method</emphasis> to be used as part <link linkend="AC">DI</link>.
-This is treated as <emphasis>explicit binding</emphasis> between declared return type and actual return type.
-This method is expected to be part of the <literal>@Binder</literal>.
-Can be used to implement custom scopes.</simpara>
-<requirement xml:id="IDE-149">
-<title>DI Provides</title>
-<simpara>
-<anchor xml:id="Req-IDE-149" xreflabel="[Req-IDE-149]"/>
-<emphasis role="strong">Requirement: IDE-149:</emphasis>
-<link linkend="Req-IDE-149">DI Provides</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Allowed only on <literal>N4MethodDeclarations</literal> that are part of a classifier annotated with <literal>@Binder</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Annotated method declared type returns instance of one of the types described in <emphasis>injectable values</emphasis> <xref linkend="_validation-of-callsites-targeting-n4injector-methods"/>.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="_n4js-di-inject">
-<title>N4JS DI @Inject</title>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>name</term>
-<listitem>
-<simpara>@Inject</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>targets</term>
-<listitem>
-<simpara>N4Field, N4Method, constructor</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>retention policy</term>
-<listitem>
-<simpara>RUNTIME</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>transitive</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>repeatable</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara><literal>@Inject</literal> defines the injection point into which an instance object will be injected.
-The specific instance depends on the injector configuration (bindings) used.
-Class fields, methods and constructors can be annotated. See <xref linkend="_injection-points"/> for more information.</simpara>
-<requirement xml:id="IDE-150">
-<title>DI Inject</title>
-<simpara>
-<anchor xml:id="Req-IDE-150" xreflabel="[Req-IDE-150]"/>
-<emphasis role="strong">Requirement: IDE-150:</emphasis>
-<link linkend="Req-IDE-150">DI Inject</link> (ver. 1)</simpara>
- <simpara>
-
-1. Injection point bindings need to be resolvable.
-2. Binding for given type must not be duplicated.
-3. Annotated types must be instances of one of the types described in <xref linkend="_validation-of-callsites-targeting-n4injector-methods"/>.</simpara>
-</requirement>
-</section>
-<section xml:id="_n4js-di-singleton">
-<title>N4JS DI @Singleton</title>
-<informaltable frame="none" rowsep="0" colsep="0">
-<tgroup cols="3">
-<colspec colname="col_1" colwidth="33.3333*"/>
-<colspec colname="col_2" colwidth="33.3333*"/>
-<colspec colname="col_3" colwidth="33.3334*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>name</term>
-<listitem>
-<simpara>@Singleton</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>targets</term>
-<listitem>
-<simpara>N4Class</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>retention policy</term>
-<listitem>
-<simpara>RUNTIME</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-<row>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>transitive</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>repeatable</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-<entry align="left" valign="top"><variablelist>
-<varlistentry>
-<term>arguments</term>
-<listitem>
-<simpara>NO</simpara>
-</listitem>
-</varlistentry>
-</variablelist></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>In the case of annotating a class <literal>S</literal> with <literal>@Singleton</literal> on the definition-site, the singleton scope will be used as described in <xref linkend="_singleton-scope"/>.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_test-support" role="language-n4js">
-<title>Test Support</title>
-<simpara>N4JS provides some annotations for testing. Most of these annotations are similar to annotations found in JUnit 4.
-For details see our Mangelhaft test framework (stdlib specification) and the N4JS-IDE specification.</simpara>
-<simpara>In order to enable tests for private methods, test projects may define which project they are testing.</simpara>
-<requirement xml:id="IDE-151">
-<title>Test API methods and types</title>
-<simpara>
-<anchor xml:id="Req-IDE-151" xreflabel="[Req-IDE-151]"/>
-<emphasis role="strong">Requirement: IDE-151:</emphasis>
-<link linkend="Req-IDE-151">Test API methods and types</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>In some cases, types or methods are only provided for testing purposes.
-In order to improve usability, e.g. content assist, these types and methods can be annotated with <literal>@TestAPI</literal>.
-There are no constraints defined for that annotation at the moment.</simpara>
-</requirement>
-</section>
-<section xml:id="_polyfill-definitions" role="language-n4js">
-<title>Polyfill Definitions</title>
-<simpara>In plain JavaScript, so called <emphasis>polyfill</emphasis> (or sometimes called <emphasis>shim</emphasis>) libraries are provided in order to modify existing classes which are only prototypes in plain JavaScript.
-In N4JS, this can be defined for declarations via the annotation <literal>@Polyfill</literal> or <literal>@StaticPolyfill</literal>.
-One of these annotations can be added to class declarations which do not look that much different from normal classes.
-In the case of polyfill classes, the extended class is modified (or filled) instead of being subclassed. It is therefore valid to polyfill a class even if it is declared <literal>@Final</literal>.</simpara>
-<simpara>We distinguish two flavours of polyfill classes: runtime and static.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Runtime polyfilling covers type enrichment for runtime libraries.
-For type modifications the annotation <literal>@Polyfill</literal> is used.</simpara>
-</listitem>
-<listitem>
-<simpara>Static polyfilling covers code modifications for adapting generated code.
-The annotation <literal>@StaticPolyfill</literal> denotes a polyfill in ordinary code, which usually provides executable implementations.</simpara>
-</listitem>
-</itemizedlist>
-<definition>
-<title>Polyfill Class</title>
-<simpara>
-<anchor xml:id="polyfill_class" xreflabel="[polyfill_class]"/>
-<emphasis role="strong">Definition:</emphasis>
-<link linkend="polyfill_class">Polyfill Class</link></simpara>
-<simpara>
-
-A <emphasis>polyfill class</emphasis> (or simply <emphasis>polyfill</emphasis>) is
-a class modifying an existing one. The polyfill is not a new class (or type) on its own.
-Instead, new members defined in the polyfill are added to the modified class and existing members can be modified similarly to overriding.
-We call the modified class the <emphasis>filled</emphasis> class and the modification <emphasis>filling</emphasis>.</simpara>
-<simpara>We add a new pseudo property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi></math> to classes in order to distinguish between normal (sub-) classes and polyfill classes.</simpara>
-</definition>
-<requirement xml:id="IDE-152">
-<title>Polyfill Class</title>
-<simpara>
-<anchor xml:id="Req-IDE-152" xreflabel="[Req-IDE-152]"/>
-<emphasis role="strong">Requirement: IDE-152:</emphasis>
-<link linkend="Req-IDE-152">Polyfill Class</link> (ver. 1)</simpara>
- <simpara>
-
-For a polyfill class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> annotated with <literal>@Polyfill</literal> or <literal>@StaticPolyfill</literal>, that is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi><mo>.</mo><mi>p</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>, all the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> must extend a class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> is called the filled class:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>P</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mo>=</mo><mi>F</mi></math>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math>’s name equals the name of the filled class and is contained in a module with same qualified name (specifier or global):<?asciidoc-br?></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mspace width="3.0mm"/><mi>P</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mo>∧</mo><mi>P</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>g</mi><mi>l</mi><mi>o</mi><mi>b</mi><mi>a</mi><mi>l</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>g</mi><mi>l</mi><mi>o</mi><mi>b</mi><mi>a</mi><mi>l</mi></mtd></mtr><mtr><mtd><mspace width="3.0mm"/><mo>∧</mo><mrow><mo>(</mo><mi>P</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>g</mi><mi>l</mi><mi>o</mi><mi>b</mi><mi>a</mi><mi>l</mi></mrow></mtd></mtr><mtr><mtd><mrow><mspace width="3.0mm"/><mspace width="3.0em"/><mo>∨</mo><mi>P</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mo>)</mo></mrow></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara>Both the polyfill and filled class must be top-level declarations (i.e., no class expression):<?asciidoc-br?></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>P</mi><mo>.</mo><mi>t</mi><mi>o</mi><mi>p</mi><mi>L</mi><mi>e</mi><mi>v</mi><mi>e</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle><mo>∧</mo><mi>F</mi><mo>.</mo><mi>t</mi><mi>o</mi><mi>p</mi><mi>L</mi><mi>e</mi><mi>v</mi><mi>e</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> must not implement any interfaces:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>P</mi><mo>.</mo><mi>i</mi><mi>m</mi><mi>p</mi><mi>l</mi><mi>e</mi><mi>m</mi><mi>e</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>d</mi><mi>I</mi><mi>n</mi><mi>t</mi><mi>e</mi><mi>r</mi><mi>f</mi><mi>a</mi><mi>c</mi><mi>e</mi><mi>s</mi><mo>=</mo><mi>∅</mi></math>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> must have the same access modifier (access, abstract, final) as the filled class:<?asciidoc-br?></simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mi>P</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>a</mi><mi>c</mi><mi>c</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi></mtd></mtr><mtr><mtd><mi>P</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>a</mi><mi>b</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>a</mi><mi>c</mi><mi>t</mi></mtd></mtr><mtr><mtd><mi>P</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>f</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> declares a constructor, it must be override compatible with the constructor of the filled class:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∃</mo><mi>P</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>C</mi><mi>t</mi><mi>o</mi><mi>r</mi><mi>:</mi><mi>P</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>C</mi><mi>t</mi><mi>o</mi><mi>r</mi><mspace width="1.0mm"/><mo><</mo><mstyle mathvariant="monospace"><mtext>:</mtext></mstyle><mspace width="1.0mm"/><mi>F</mi><mo>.</mo><mi>c</mi><mi>t</mi><mi>o</mi><mi>r</mi></math>
-</listitem>
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> must define the same type variables as the filled class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> and the arguments must be in the same order as the parameters (with no further modifications):</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mo>∀</mo><mi>i</mi><mo>,</mo><mn>0</mn><mo>≤</mo><mi>i</mi><mo><</mo><mo>|</mo><mi>P</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><mi>s</mi><mo>|</mo><mi>:</mi></mtd></mtr><mtr><mtd><mspace width="3.0em"/><mi>P</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>i</mi></msub><mo>=</mo><mi>F</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>i</mi></msub></mtd></mtr><mtr><mtd><mspace width="3.0em"/><mo>∧</mo><mi>P</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>P</mi><mi>a</mi><mi>r</mi><msub><mi>s</mi><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>P</mi><mo>.</mo><mi>s</mi><mi>u</mi><mi>p</mi><mi>e</mi><mi>r</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>A</mi><mi>r</mi><mi>g</mi><msub><mi>s</mi><mi>i</mi></msub><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara>All constraints related to member redefinition (cf. <xref linkend="_redefinition-of-members"/>) have to hold.
-In the case of polyfills, this is true for constructors (cf. <xref linkend="Req-IDE-72"/>) and private members.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<section xml:id="_runtime-polyfill-definitions">
-<title>Runtime Polyfill Definitions</title>
-<simpara>(Runtime) Libraries often do not provide completely new types but modify existing types.
-The ECMA-402 Internationalization Standard [<link linkend="ECMA12a">ECMA12a</link>], for example, changes methods of the built-in class <literal>Date</literal> to be timezone aware.
-Other scenarios include new functionality provided by browsers which are not part of an official standard yet.
-Even ECMAScript 6 [<link linkend="ECMA15a">ECMA15a</link>] extends the predecessor [<link linkend="ECMA11a">ECMA11a</link>] in terms of new methods (or new method parameters) added to existing types (it also adds completely new classes and features, of course).</simpara>
-<simpara>Runtime polyfills are only applicable to runtime libraries or environments and thus are limited to n4jsd files.</simpara>
-<requirement xml:id="IDE-153">
-<title>Runtime Polyfill Class</title>
-<simpara>
-<anchor xml:id="Req-IDE-153" xreflabel="[Req-IDE-153]"/>
-<emphasis role="strong">Requirement: IDE-153:</emphasis>
-<link linkend="Req-IDE-153">Runtime Polyfill Class</link> (ver. 1)</simpara>
- <simpara>
-
-For a runtime-polyfill class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> annotated with <literal>@Polyfill</literal>, that is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>p</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>false</mtext></mstyle></math>, all the following constraints must hold in addition to <xref linkend="Req-IDE-152"/>:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Both the polyfill and filled class are provided by the runtime
-(annotated with <literal>@ProvidedByRuntime</literal>): <footnote><simpara>This restriction has two reasons: Firstly, user-defined types with implementations would require to ’bootstrap’ the polyfill, which is impossible to do automatically without serious constraints on bootstrap code in general. Secondly, instead of filling user-defined types, they can be subclasses. Mechanisms such as dependency injection could then solve almost all remaining problems.</simpara></footnote></simpara>
-</listitem>
-</orderedlist>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>P</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>v</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>d</mi><mi>B</mi><mi>y</mi><mi>R</mi><mi>u</mi><mi>n</mi><mi>t</mi><mi>i</mi><mi>m</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle><mo>∧</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>v</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>d</mi><mi>B</mi><mi>y</mi><mi>R</mi><mi>u</mi><mi>n</mi><mi>t</mi><mi>i</mi><mi>m</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>
-</requirement>
-<requirement xml:id="IDE-154">
-<title>Applying Polyfills</title>
-<simpara>
-<anchor xml:id="Req-IDE-154" xreflabel="[Req-IDE-154]"/>
-<emphasis role="strong">Requirement: IDE-154:</emphasis>
-<link linkend="Req-IDE-154">Applying Polyfills</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>A polyfill is automatically applied if a runtime library or environment required by the current project provides it. In this case, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>No member must be filled by more than one polyfill.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="_static-polyfill-definitions">
-<title>Static Polyfill Definitions</title>
-<simpara>Static polyfilling is a compile time feature to enrich the definition and usually also the implementation of generated code in N4JS. It is related to runtime polyfilling described in <xref linkend="_runtime-polyfill-definitions"/> in a sense that both fillings enrich the types they address. Despite this, static polyfilling and runtime polyfilling differ in the way they are handled.</simpara>
-<simpara>Static polyfills usually provide executable implementations and are thus usually found in n4js files. However, they are allowed in n4jsd files, as well, for example to enrich generated code in an API project.</simpara>
-<simpara>The motivation for static polyfills is to support automatic code generation.
-In many cases, automatically generated code is missing some information to make it sufficiently usable in the desired environment.
-Manual enhancements usually need to be applied.
-If we think of a toolchain, the question may arise how to preserve the manual work when a
-regeneration is triggered. Static polyfilling allows the separation of generated code and manual adjustments in separate files.
-The transpiler merges the two files into a single transpiled file.
-To enable this behaviour, the statically fillable types must be contained in a module annotated with <literal>@StaticPolyfillAware</literal>.
-The filling types must also be annotated with <literal>@StaticPolyfill</literal> and be contained in a different module with same specifier but annotated with <literal>@StaticPolyfillModule</literal>.
-Static polyfilling is restricted to a project, thus the module to be filled as well as the filling module must be contained in the same project.</simpara>
-<simpara>We add a new pseudo property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi></math> to classes in order to distinguish between normal (sub-) classes and static polyfill classes.
-We add two new pseudo properties to modules in order to modify the transpilation process.
-The mutually-exclusive properties <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mi>A</mi><mi>w</mi><mi>a</mi><mi>r</mi><mi>e</mi></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi></math> signal the way these files are processed.</simpara>
-<simpara>In order to support efficient transpilation, the following constraint must hold in addition to constraints:</simpara>
-<requirement xml:id="IDE-155">
-<title>Static Polyfill Layout</title>
-<simpara>
-<anchor xml:id="Req-IDE-155" xreflabel="[Req-IDE-155]"/>
-<emphasis role="strong">Requirement: IDE-155:</emphasis>
-<link linkend="Req-IDE-155">Static Polyfill Layout</link> (ver. 1)</simpara>
- <simpara>
-
-For a static polyfill class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math> annotated with <literal>@StaticPolyfill</literal>, that is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>p</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>, all the following constraints must hold in addition to <xref linkend="Req-IDE-152"/>:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>P</mi></math>’s name equals the name of the filled class and is contained in a module with the same qualified name:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mtable><mtr><mtd><mi>P</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi></mtd></mtr><mtr><mtd><mo>∧</mo><mi>P</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi></mtd></mtr></mtable></math>
-</listitem>
-<listitem>
-<simpara>Both the static polyfill and the filled class are part of the same project:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>P</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi><mo>=</mo><mi>F</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi></math>
-</listitem>
-<listitem>
-<simpara>The filled class must be contained in a module annotated with <literal>@StaticPolyfillAware</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>F</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mi>A</mi><mi>w</mi><mi>a</mi><mi>r</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>
-</listitem>
-<listitem>
-<simpara>The static polyfill and the filled type must both be declared in an n4js file or both in an n4jsd file.</simpara>
-</listitem>
-<listitem>
-<simpara>The filling class must be contained in a module annotated with <literal>@StaticPolyfillModule</literal>:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mi>P</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>
-</listitem>
-<listitem>
-<simpara>For a statically-filled class <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi></math> there is at most one static polyfill:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close=")" open="("><mrow><msub><mi>P</mi><mn>1</mn></msub><mstyle mathvariant="monospace"><mspace width="1ex"/><mtext>is static polyfill of</mtext><mspace width="1ex"/></mstyle><mi>F</mi><mo>∧</mo><msub><mi>P</mi><mn>2</mn></msub><mstyle mathvariant="monospace"><mspace width="1ex"/><mtext>is static polyfill of</mtext><mspace width="1ex"/></mstyle><mi>F</mi></mrow></mfenced><mo>→</mo><msub><mi>P</mi><mn>1</mn></msub><mo>=</mo><msub><mi>P</mi><mn>2</mn></msub></math>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-156">
-<title>Restrictions on static polyfilling</title>
-<simpara>
-<anchor xml:id="Req-IDE-156" xreflabel="[Req-IDE-156]"/>
-<emphasis role="strong">Requirement: IDE-156:</emphasis>
-<link linkend="Req-IDE-156">Restrictions on static polyfilling</link> (ver. 1)</simpara>
- <simpara>
-
-For a static polyfilling module <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>P</mi></msub></math> the following must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>All top-level elements are static polyfills:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><mo>∀</mo><mi>T</mi><mo>∈</mo><msub><mi>M</mi><mi>P</mi></msub><mo>∧</mo><mi>T</mi><mo>.</mo><mi>t</mi><mi>o</mi><mi>p</mi><mi>L</mi><mi>e</mi><mi>v</mi><mi>e</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></mrow><mrow><mi>T</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></mrow></mfrac></math>
-</listitem>
-<listitem>
-<simpara>It exists exactly one filled module <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>M</mi><mi>F</mi></msub></math> annotated with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mi>A</mi><mi>w</mi><mi>a</mi><mi>r</mi><mi>e</mi></math> in the same project.</simpara>
-</listitem>
-<listitem>
-<simpara>It is an error if two static polyfill modules for the same filled module exist in the same project:</simpara>
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfrac><mrow><msub><mi>M</mi><mn>1.</mn></msub><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mo>=</mo><msub><mi>M</mi><mn>2.</mn></msub><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mo>∧</mo><msub><mi>M</mi><mn>1.</mn></msub><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi><mo>=</mo><msub><mi>M</mi><mn>2.</mn></msub><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi><mtext>
-</mtext><mo>∧</mo><msub><mi>M</mi><mn>1.</mn></msub><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mo>=</mo><msub><mi>M</mi><mn>2.</mn></msub><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></mrow><mrow><msub><mi>M</mi><mn>1</mn></msub><mo>=</mo><msub><mi>M</mi><mn>2</mn></msub></mrow></mfrac></math>
-</listitem>
-</orderedlist>
-</requirement>
-<example>
-<title>Static polyfill</title>
-<simpara><xref linkend="ex:staticpolyfill-genmod"/> shows an example of generated code.
-<xref linkend="ex:staticpolyfill-polyfillmod"/> demonstrates the static polyfill.</simpara>
-<simpara>Note that the containing project has two source folders configured:<?asciidoc-br?>
-<literal>Project/src/n4js</literal> and <literal>Project/src/n4jsgen</literal>.</simpara>
-<formalpara xml:id="ex:staticpolyfill-polyfillmod">
-<title>Static Polyfill, Polyfillmod</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">@@StaticPolyfillAware
-export public class A {
- constructor() {...}
- m1(): void{...}
-}
-export public class B {
- constructor() {...}
- m2(): void{...}
-}</programlisting>
-</para>
-</formalpara>
-<formalpara xml:id="ex:staticpolyfill-genmod">
-<title>Static Polyfill, Genmod</title>
-<para>
-<programlisting language="n4js" linenumbering="unnumbered">@@StaticPolyfillModule
-@StaticPolyfill
-export public class B extends B {
- @Override
- constructor(){ ... } // replaces generated ctor of B
- @Override
- m1(): void {...} // adds overridden method m1 to B
- @Override
- m2(): void {...} // replaces method m2 in B
- m3(): void {...} // adds new method m3 to B
-}</programlisting>
-</para>
-</formalpara>
-</example>
-</section>
-<section xml:id="_transpiling-static-polyfilled-classes">
-<title>Transpiling static polyfilled classes</title>
-<simpara>Transpiling static polyfilled classes encounters the special case that two different <literal>n4js</literal> source files with the same qualified name are part of the project.
-Since the current transpiler is file-based, both files would be transpiled to the same output destination and would therefore overwrite each other.
-The following pre-transpilation steps handle this situation:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Current file to transpile is <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mi>A</mi><mi>w</mi><mi>a</mi><mi>r</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>, then</simpara>
-<itemizedlist>
-<listitem>
-<simpara>search for a second file <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi></math> with same qualified name:<?asciidoc-br?>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi><mo>.</mo><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mo>=</mo><mi>M</mi><mo>.</mo><mi>s</mi><mi>p</mi><mi>e</mi><mi>c</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>r</mi><mo>∧</mo><mi>G</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi><mo>=</mo><mi>M</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi></math></simpara>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∃</mo><mi>G</mi></math>, then</simpara>
-<itemizedlist>
-<listitem>
-<simpara>merge <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>G</mi></math> into current file <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mo>→</mo><msup><mi>M</mi><mi>'</mi></msup></math></simpara>
-</listitem>
-<listitem>
-<simpara>conventionally transpile <math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mi>M</mi><mi>'</mi></msup></math></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>else conventionally transpile <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math></simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>else, if <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi><mo>.</mo><mi>s</mi><mi>t</mi><mi>a</mi><mi>t</mi><mi>i</mi><mi>c</mi><mi>P</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mi>M</mi><mi>o</mi><mi>d</mi><mi>u</mi><mi>l</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>,</simpara>
-<itemizedlist>
-<listitem>
-<simpara>then <emphasis>do nothing</emphasis>. (Transpilation will be triggered for filled type separately.)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>else, conventionally transpile <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math></simpara>
-</listitem>
-</itemizedlist>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_components">
-<title>Components</title>
-<section xml:id="_overview-2" role="language-n4js">
-<title>Overview</title>
-<simpara>For modularization purposes, N4JS code is managed in so-called <emphasis>components</emphasis>. These components correspond to what
-node and npm call <emphasis>packages</emphasis>, what OSGi calls <emphasis>bundle</emphasis>, and what Eclipse calls <emphasis>project</emphasis>.</simpara>
-<simpara>N4JS distinguishes several types of such components. <xref linkend="fig-cmpd_components_in_n4js"/> shows the N4JS component types
-described in detail in this chapter. <xref linkend="fig-cmp_components"/> shows a recently updated diagram, which is not yet fully
-reflected in the implementation.</simpara>
-<figure xml:id="fig-cmpd_components_in_n4js">
-<title>Overview of N4JS Components (OLD)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/12_components/fig/cmpd_components_in_n4js.svg" align="center"/>
-</imageobject>
-<textobject><phrase>cmpd components in n4js</phrase></textobject>
-</mediaobject>
-</figure>
-<figure xml:id="fig-cmp_components">
-<title>Overview of N4JS Components and Dependencies (NEW)</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/12_components/fig/cmp_components.svg" align="center"/>
-</imageobject>
-<textobject><phrase>cmp components</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>The following types of components can only be created by internal developers:</simpara>
-<variablelist>
-<varlistentry>
-<term>Runtime Environment</term>
-<listitem>
-<simpara>Definition of a runtime environment such as ECMAScript 5, node.js, or Chrome.
-A Runtime Environment provides a number of base types which are usually globally available.
-Other components do not directly rely on runtime environments, but on runtime libraries.
-NOTE: runtime environments are not fully implemented at this time (see GH-1291).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Runtime Library</term>
-<listitem>
-<simpara>Contains type definitions for the base types provided by one or more runtime environments.
-These types may be extensions to certain language specifications.
-E.g., the ECMAScript 6 collection classes are already provided by some environments otherwise only supporting ECMAScript 5.
-The collections are defined in terms of a runtime library which can then be provided by these environments.
-Runtime libraries may also contain polyfills to alter types predefined in the environment.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The following components can be created by external developers:</simpara>
-<variablelist xml:id="App">
-<varlistentry>
-<term>App</term>
-<listitem>
-<simpara>User-written N4JS applications.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Processor</term>
-<listitem>
-<simpara>User-written N4JS code running server-side on the N4 platform. Not implemented yet.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Library</term>
-<listitem>
-<simpara>User-written libraries used by apps, processors, or other libraries.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>The available component types are described in more detail in <xref linkend="Component_Types"/>.</simpara>
-<simpara>A component corresponds to a single project in the N4JS IDE. Generally, it contains the following:</simpara>
-<variablelist>
-<varlistentry>
-<term>Package.json File</term>
-<listitem>
-<simpara>The <literal>package.json</literal> file describing the contents, dependencies and metadata.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Resources</term>
-<listitem>
-<simpara>Resources such as images, data files etc.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Sources</term>
-<listitem>
-<simpara>Source files containing either N4JS code or plain Javascript. The actual code used in a project.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Output Code</term>
-<listitem>
-<simpara>Compiled and possibly adjusted (e.g. minified, concatenated) versions of the N4JS source files and
-plain Javascript files.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Tests</term>
-<listitem>
-<simpara>Optional test sources and compiled output code.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>Source Maps</term>
-<listitem>
-<simpara>Optional source maps.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Components contain modules. <xref linkend="fig-component_content"/> describes what can be contained in a component.</simpara>
-<figure xml:id="fig-component_content">
-<title>Content of a Component</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/12_components/fig/cmpd_component_content.svg" width="70%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>cmpd component content</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>At both compile time and runtime, all components defined as dependency have to be available. Since dependencies
-are defined in <literal>package.json</literal> files in a form compliant to node/npm, this can be fully managed by npm (or yarn).</simpara>
-</section>
-<section xml:id="Component_Types" role="language-n4js">
-<title>Component Types</title>
-<simpara>Different N4JS component types are described in this section.</simpara>
-<section xml:id="_libraries">
-<title>Libraries</title>
-<simpara>A library is a user project providing modules with declaration.</simpara>
-</section>
-<section xml:id="_runtime-environment-and-runtime-libraries">
-<title>Runtime Environment and Runtime Libraries</title>
-<note>
-<simpara>runtime environments are not fully implemented at this time (see GH-1291).</simpara>
-</note>
-<simpara>Runtime environments and libraries define globally available elements (types, variables, functions) provided by the JavaScript engine.
-Both must contain <emphasis>only</emphasis> definition files (n4jsd) of which all elements are marked as <literal>@ProvidedByRuntime</literal> (<xref linkend="_runtime-definitions"/>) and <literal>@Global</literal> (<xref linkend="_global-definitions"/>).</simpara>
-<simpara>Other projects may refer to <emphasis>multiple</emphasis> runtime libraries in their <literal>package.json</literal> file via the property <xref linkend="package-json-requiredRuntimeLibraries"/>.</simpara>
-<simpara>The concrete runtime environment and library are selected by the JavaScript engine.
-Deployment and execution scripts must ensure that a component can run on the given engine; the required environments and libraries must all be compatible with the provided environment.
-If no runtime environment is specified, a default an ECMAScript 5 runtime is assumed to be present.</simpara>
-<simpara>Typical runtime environments are ES5 or ES6, typical runtime libraries are DOM or HTML.</simpara>
-<simpara>In JavaScript, browsers and other execution environments provide built-in objects.
-In browsers, for example, the whole DOM is made available via built-in object types.
-In this case, even the global object also becomes a different type (in N4JS terms).
-Besides execution environments such as browsers or Node.js, libraries also provide functionality by exposing globally available functions.
-This is often used to bridge execution environment inconsistencies.
-When browser API differences are adapted by a library, this is called a <emphasis>polyfil</emphasis>.
-Other adaptations, such as enabling ECMSScript 6 object types in ECMAScript 5 environments, are known as <emphasis>shim</emphasis>.
-Instead of directly supporting these kind of 'hacks', other components specify which runtime environment and libraries they depend on by specifying unique runtime ids.
-Possible shims (in case of environments) or polyfils (in case of libraries) are transparently provided by the execution environment and the bootstrap code.</simpara>
-</section>
-<section xml:id="_tests">
-<title>Tests</title>
-<simpara>Tests are special projects which contain tests for other projects.</simpara>
-<requirement xml:id="IDE-157">
-<title>Test Project</title>
-<simpara>
-<anchor xml:id="Req-IDE-157" xreflabel="[Req-IDE-157]"/>
-<emphasis role="strong">Requirement: IDE-157:</emphasis>
-<link linkend="Req-IDE-157">Test Project</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Tests have full access to the tested project including elements with <literal>project</literal> visibility.</simpara>
-</listitem>
-<listitem>
-<simpara>Only other test projects can depend on tests project.
-In other words, other components must not depend on test components.</simpara>
-</listitem>
-</orderedlist>
-<simpara>In a test project, the tested projects can be specified via <literal>testee</literal>.</simpara>
-</requirement>
-</section>
-<section xml:id="_type-definitions">
-<title>Type Definitions</title>
-<simpara>Projects of type "definition" are special projects which only provide type information for another so-called <emphasis>implementation project</emphasis>, which only provides executable JS files.</simpara>
-<simpara>Generally, client projects that depend on a given <emphasis>implementation project</emphasis> may additionally declare a dependency on a corresponding type definitions project, in order to integrate type information on the implementation project.
-This is implemented by means of module-level shadowing.
-More specifically, given a client imports a module with module specifier <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math> from the implementation project.
-When resolving the module specifier, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>M</mi></math> will first be resolved against the implementation project’s type definitions and only secondarily against the implementation project.
-As a consequence, type definition projects may only provide partial type information, while the remaining modules of the implementation project remain accessible through dynamic namespace imports.</simpara>
-<requirement xml:id="GH-821002">
-<title>Type Definition Project Configuration</title>
-<simpara>
-<anchor xml:id="Req-GH-821002" xreflabel="[Req-GH-821002]"/>
-<emphasis role="strong">Requirement: GH-821002:</emphasis>
-<link linkend="Req-GH-821002">Type Definition Project Configuration</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For type definition projects, the following constraints must hold true with regard to their project configuration:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>They must declare their <emphasis>implementation project</emphasis> via the <xref linkend="package-json-definesPackage"/> property in their <literal>package.json</literal> file.</simpara>
-</listitem>
-<listitem>
-<simpara>They must not declare an output folder.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-</section>
-<section xml:id="package-json" role="language-n4js" xreflabel="Package.json File">
-<title>Package.json File</title>
-<simpara>A folder is a "component" if and only if it contains a <literal>package.json</literal> file. Being a component means
-that this folder is recognized by all N4JS-related tools but does not necessarily mean the component
-contains N4JS code (it could just contain plain Javascript). The main benefit of being a component
-in this sense is that this unit of code can be used by other N4JS components as a dependency.</simpara>
-<simpara>For example, a plain npm project containing only plain Javascript can be a component and
-can therefore be used as a project dependency of a full-blown N4JS component.</simpara>
-<section xml:id="_basic-properties">
-<title>Basic Properties</title>
-<simpara>The following standard <literal>package.json</literal> properties are used by N4JS tooling. Unless otherwise
-noted, all these properties have the exact same format and meaning as usual in <literal>package.json</literal>
-files.</simpara>
-<variablelist>
-<varlistentry>
-<term>name </term>
-<listitem>
-<simpara>Used as the globally unique identifier of the component.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>version </term>
-<listitem>
-<simpara>The component’s version.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<variablelist xml:id="package-json-dependencies" xreflabel="dependencies">
-<varlistentry>
-<term>dependencies </term>
-<listitem>
-<simpara>List of components required at runtime and compile time.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<variablelist xml:id="package-json-devDependencies" xreflabel="devDependencies">
-<varlistentry>
-<term>devDependencies </term>
-<listitem>
-<simpara>List of components required at compile time only.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>main </term>
-<listitem>
-<simpara>Path relative to the component’s root folder, pointing to a <literal>.js</literal> file
-located in a source container (the <literal>.js</literal> file extension is optional,
-i.e. may be omitted). This file then serves as the component’s
-default entry point, i.e. project imports pointing to this component from
-other components will import from the file denoted by this property. In
-addition, this property may denote a folder and is then assumed to point
-to a file <literal>index.js</literal> located in that folder. If this property denotes a file
-other than a <literal>.js</literal> file, it will be ignored. In particular, it cannot be
-used for <literal>.n4js</literal> files; in that case, property "mainModule" has to be used
-(see below).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>workspaces </term>
-<listitem>
-<simpara>(array of strings) Property used by package management tool <literal>yarn</literal> to denote
-that a project serves as a "yarn workspace" and to denote the other projects
-that form the members of this yarn workspace. For details, see
-<link xl:href="https://yarnpkg.com/lang/en/docs/workspaces">here</link>.
-In N4JS, a project is called a "yarn workspace root" if and only if its
-<literal>package.json</literal> file contains top-level property "workspaces", no matter the property’s
-value (i.e. it will be called "yarn workspace root" even if the value of property
-"workspaces" is the empty array or an invalid value such as a number). The nested
-projects referred to via the strings in this property’s array value are called
-"member projects" of the yarn workspace.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_n4js-properties">
-<title>N4JS Properties</title>
-<simpara>In addition to the standard properties above, there is a single N4JS-specific
-top-level property called "n4js". The value of this property must always be
-an object that may have any combination of the following properties:</simpara>
-<variablelist>
-<varlistentry>
-<term>projectType</term>
-<listitem>
-<simpara>(string) Must be one of the following strings:</simpara>
-<variablelist>
-<varlistentry>
-<term>application</term>
-<listitem>
-<simpara>An application. See <xref linkend="App"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>library</term>
-<listitem>
-<simpara>A library. See <xref linkend="_libraries"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>processor</term>
-<listitem>
-<simpara>For processors running server-side on the N4 platform. Not implemented yet.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>test</term>
-<listitem>
-<simpara>An N4JS project containing tests for one or more other N4JS projects specified
-via property "testedProjects".</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>api</term>
-<listitem>
-<simpara>For N4JS projects that contain only API (in <literal>.n4jsd</literal> files) to be implemented by other,
-so-called implementation projects. See properties "implementationId", "implementedProjects".
-NOTE: the API/Implementation concept is not fully implemented at this time (see GH-1291).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>runtimeEnvironment</term>
-<listitem>
-<simpara>Runtime environments. See <xref linkend="Runtime Environment Resolution"/>.
-NOTE: runtime environments are not fully implemented at this time (see GH-1291).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>runtimeLibrary</term>
-<listitem>
-<simpara>Runtime libraries. See <xref linkend="_runtime-environment-and-runtime-libraries"/>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>validation</term>
-<listitem>
-<simpara>A project in which <literal>.n4js</literal> files are only being validated, not transpiled. This is used for projects
-that are implemented in terms of <literal>.js</literal> files but that also provide type information in terms of <literal>.n4jsd</literal> files.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>plainjs</term>
-<listitem>
-<simpara>A project which only contains <literal>.js</literal> files and no N4JS resources. The contained JS files are only indexed to allow
-for dynamic imports of specific JavaScript modules. Projects of this type are not being transpiled.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>vendorId</term>
-<listitem>
-<simpara>(string) Globally unique identifier for the component’s vendor.
-Used for the <literal>@Internal</literal> accessibility modifier.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>vendorName</term>
-<listitem>
-<simpara>(string) Human-readable name of the component’s vendor. Used only for informational
-purposes.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>output</term>
-<listitem>
-<simpara>(string) Path relative to the component’s root folder, pointing to a folder where
-all output files will be placed. In particular, this is where the N4JS transpiler
-will put the <literal>.js</literal> files created for each <literal>.n4js</literal> file.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>sources</term>
-<listitem>
-<simpara>(object) Defines various sub-folders where sources, etc. are located. All properties
-of the given object must have the following format: the name must be "source", "external",
-or "test"; the value must be an array of strings, with each string defining a
-path relative to the component’s root folder, pointing to a folder where
-source files of the corresponding type are located. For example, paths given via name
-"source" tell the N4JS transpiler where to look for <literal>.n4js</literal> source files to be compiled.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>moduleFilters</term>
-<listitem>
-<simpara>(object) Filters for fine-tuning the validator and compiler. A filter is applied to modules
-matching the given module specifier which may contain wildcards, optionally restricted to
-modules defined in a specific source path.</simpara>
-<simpara>All properties of the given object must have the following format: the name must be a valid
-module filter type (see below); the value must be an array of strings, with each string
-defining a pattern of files inside one of the source containers for which validation or
-module wrapping is to be turned off. Instead of a plain string, the inner array may
-contain an object with properties "module" and "sourceContainer" to make this filter apply
-to only one of the source containers (instead of all source containers, which is the default).</simpara>
-<variablelist>
-<varlistentry>
-<term>noValidate</term>
-<listitem>
-<simpara>Modules matching this filter are not semantically validated.
-That is, they are still syntactically validated.
-If they are contained in source or test source fragments, it must be possible to bind references
-to declarations inside these modules.
-Note that switching off validation for n4js files is disallowed.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</listitem>
-</varlistentry>
-</variablelist>
-<example>
-<title>Module Filters</title>
-<simpara>A simple and a source-container-specific module filter in the <literal>n4js</literal> section of a package.json file.</simpara>
-<programlisting language="json" linenumbering="unnumbered">"moduleFilters": {
- "noValidate": [
- "abc*",
- {
- "module": "xyz*",
- "sourceContainer": "src/n4js"
- }
- ]
-}</programlisting>
-</example>
-<variablelist xml:id="package-json-mainModule" xreflabel="mainModule">
-<varlistentry>
-<term>mainModule</term>
-<listitem>
-<simpara>(string) A plain module specifier defining the project’s 'main module'.
-If this property is defined, other projects can import from this project using imports where the string following
-keyword <literal>from</literal> states only the project name and not the complete module specifier (see <xref linkend="import-statement-semantics"/>).
-If this property is defined, top-level property <literal>main</literal> will be ignored.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>testedProjects</term>
-<listitem>
-<simpara> (array) List of N4JS components being tested by this project.
- <?asciidoc-br?>
-Only components of project type "test" may declare this property. Furthermore, the referenced
-projects must all be of the same project type and must not be of type "test" themselves.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<variablelist xml:id="package-json-implementationId" xreflabel="implementationId">
-<varlistentry>
-<term>implementationId</term>
-<listitem>
-<simpara>(string) If this property is defined, this component is called an "implementation project" and the string value
- provides a unique identifier for the implementation provided in this component. If this is defined, property
- "implementedProjects" must be defined as well. For details, see <xref linkend="API and Implementation Components"/>.</simpara>
-<simpara>Only projects of type "application", "processor", "library", "api" or "validation" may declare this property.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<variablelist xml:id="package-json-implementedProjects" xreflabel="implementedProjects">
-<varlistentry>
-<term>implementedProjects</term>
-<listitem>
-<simpara>(array) A list of API components (components of type "api") that are implemented by this component. If this
-is defined, property "implementationId" must be defined as well. For details, see
-<xref linkend="API and Implementation Components"/>. Only components of type "application", "processor", "library", "api"
-or "validation" may declare this property.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<variablelist xml:id="package-json-requiredRuntimeLibraries" xreflabel="requiredRuntimeLibraries">
-<varlistentry>
-<term>requiredRuntimeLibraries</term>
-<listitem>
-<simpara>(array) The list of required runtime library components that are required for the execution of this
- component. All components but components of type "runtime environment" may declare this property. Each
- required runtime library must also be specified as a dependency using one of the top-level
- properties <literal>dependencies</literal> or <literal>devDependencies</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>extendedRuntimeEnvironment</term>
-<listitem>
-<simpara>(string) The name of the runtime environment project that is extended by this component. Only components of
-type "runtime environment" may declare this property.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>providedRuntimeLibraries</term>
-<listitem>
-<simpara>(array) The list of runtime library components that are provided by this component. Only components of
-type "runtime environment" may declare this property.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<variablelist xml:id="package-json-definesPackage" xreflabel="definesPackage">
-<varlistentry>
-<term>definesPackage</term>
-<listitem>
-<simpara>(string) The name of the package this component provides type definitions for. Only components of project type "definition" may declare this property.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>All properties described above are optional. The following default values apply:</simpara>
-<informaltable frame="all" rowsep="1" colsep="1">
-<tgroup cols="2">
-<colspec colname="col_1" colwidth="50*"/>
-<colspec colname="col_2" colwidth="50*"/>
-<tbody>
-<row>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Property</emphasis></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Default Value</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>name</simpara></entry>
-<entry align="left" valign="top"><simpara>name of the folder containing the <literal>package.json</literal> file</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>version</simpara></entry>
-<entry align="left" valign="top"><simpara>"0.0.1"</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>projectType</simpara></entry>
-<entry align="left" valign="top"><simpara>"plainjs"</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>vendorId</simpara></entry>
-<entry align="left" valign="top"><simpara>"vendor.default"</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>mainModule</simpara></entry>
-<entry align="left" valign="top"><simpara>"index"</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>output</simpara></entry>
-<entry align="left" valign="top"><simpara>"."</simpara></entry>
-</row>
-<row>
-<entry align="left" valign="top"><simpara>sources</simpara></entry>
-<entry align="left" valign="top"><simpara>a single source-container of type "source" with path "." (except for yarn workspace roots, see below)</simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-<simpara>All other properties are undefined if not given in the <literal>package.json</literal> file. The default source folder of "." does not
-apply to projects that represent the root folder of a yarn workspace; those projects do not have any source folder,
-by default.</simpara>
-<example>
-<title>A package.json file with N4JS-specific properties.</title>
-<simpara>The following example illustrates how to use the N4JS-related package.json properties.</simpara>
-<screen>{
- "name": "SampleProject",
- "version": "0.0.1",
- "author": "Enfore AG",
- "main": "./src/js/main.js",
- "dependencies": {
- "OtherProject": ">=1.2.3 <2.0.0",
- "n4js-runtime-es2015": "latest"
- },
- "devDependencies": {
- "org.eclipse.n4js.mangelhaft": "latest"
- },
- "n4js": {
- "projectType": "library",
- "vendorId": "org.eclipse.n4js",
- "vendorName": "Eclipse N4JS Project",
- "output": "src-gen",
- "mainModule": "a/b/Main",
- "sources": {
- "source": [
- "src/n4js",
- "src/n4js-gen"
- ],
- "external": [
- "src-ext"
- ],
- "test": [
- "src-test"
- ]
- },
- "moduleFilters": {
- "noValidate": [
- "abc*",
- {
- "module": "xyz*",
- "sourceContainer": "src/n4js"
- }
- ]
- },
- "requiredRuntimeLibraries": [
- "n4js-runtime-es2015"
- ]
- }
-}</screen>
-</example>
-</section>
-<section xml:id="_constraints">
-<title>Constraints</title>
-<simpara>The following constraints apply.</simpara>
-<requirement xml:id="IDE-158">
-<title>GeneralConstraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-158" xreflabel="[Req-IDE-158]"/>
-<emphasis role="strong">Requirement: IDE-158:</emphasis>
-<link linkend="Req-IDE-158">GeneralConstraints</link> (ver. 1)</simpara>
- <simpara>
-
-1. There must be an output directory specified so the compiler(s) can run.</simpara>
-</requirement>
-<requirement xml:id="IDE-159">
-<title>Paths</title>
-<simpara>
-<anchor xml:id="Req-IDE-159" xreflabel="[Req-IDE-159]"/>
-<emphasis role="strong">Requirement: IDE-159:</emphasis>
-<link linkend="Req-IDE-159">Paths</link> (ver. 1)</simpara>
- <simpara>
-
-Paths Paths are constrained in the following way:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A path cannot appear more than one time within a source fragment type (same applies to paths in the resources section).</simpara>
-</listitem>
-<listitem>
-<simpara>A path cannot be used in different source fragment types at same times.</simpara>
-</listitem>
-<listitem>
-<simpara>A path can only be declared exclusively in one of the sections Output, Libraries, Resources or Sources.</simpara>
-</listitem>
-<listitem>
-<simpara>A path must not contain wild cards.</simpara>
-</listitem>
-<listitem>
-<simpara>A path has to be relative to the project path.</simpara>
-</listitem>
-<listitem>
-<simpara>A path has to point to folder.</simpara>
-</listitem>
-<listitem>
-<simpara>The folder a defined path points to must exist in the project (but in case of non-existent folders of source fragments, only a warning is shown).</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-160">
-<title>Module Specifiers</title>
-<simpara>
-<anchor xml:id="Req-IDE-160" xreflabel="[Req-IDE-160]"/>
-<emphasis role="strong">Requirement: IDE-160:</emphasis>
-<link linkend="Req-IDE-160">Module Specifiers</link> (ver. 1)</simpara>
- <simpara>
-
-Module Specifiers are constrained in the following
-way:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Within a module filter type no duplicate specifiers are allowed.</simpara>
-</listitem>
-<listitem>
-<simpara>A module specifier is by default applied relatively to all defined source containers, i.e. if there src and src2 defined as source containers in both folders files are looked up that matches the given module specifier</simpara>
-</listitem>
-<listitem>
-<simpara>A module specifier can be constrained to be applied only to a certain source container.</simpara>
-</listitem>
-<listitem>
-<simpara>A module specifier is allowed to contain wildcards but it must resolve to some existing files in the project</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-161">
-<title>Module Specifier Wildcard Constraints</title>
-<simpara>
-<anchor xml:id="Req-IDE-161" xreflabel="[Req-IDE-161]"/>
-<emphasis role="strong">Requirement: IDE-161:</emphasis>
-<link linkend="Req-IDE-161">Module Specifier Wildcard Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-. All path patterns are case sensitive.
-. <literal>**</literal> all module specifiers will be matched.
-. <literal>**/*</literal> all module specifiers will be matched.
-. <literal>test/A??</literal> matches all module specifiers whose qualified name consists of two segments where the first part matches test and the second part starts with an <literal>A</literal> and then two more characters.
-. <literal>**/test/**/XYZ</literal> - matches all module specifiers whose qualified name contains a segment that matches test and the last segment ends with an ’XYZ’.
-. A module specifier wild card isn’t allowed to contain <literal>***</literal>.
-. A module specifier wild card isn’t allowed to contain relative navigation.
-. A module specifier wild card shouldn’t contain the file extension (only state the file name (pattern) without extension, valid file extensions will then be used to match the file).</simpara>
-</requirement>
-<simpara>Examples of using external source fragments and filters are given in <xref linkend="_implementation-of-external-declarations"/>, see <xref linkend="external-definitions-and-implementations"/>.</simpara>
-<requirement xml:id="GH-821001">
-<title>Dependencies to Definition Projects</title>
-<simpara>
-<anchor xml:id="Req-GH-821001" xreflabel="[Req-GH-821001]"/>
-<emphasis role="strong">Requirement: GH-821001:</emphasis>
-<link linkend="Req-GH-821001">Dependencies to Definition Projects</link> (ver. 1)</simpara>
- <simpara>
-
-. For each listed project dependency of type "definition", a corresponding dependency (in the (dev)dependencies section) must be declared, whose "name" matches the "definesPackage" property value of the definition project.</simpara>
-</requirement>
-</section>
-</section>
-<section xml:id="_support-for-npm-scopes" role="language-n4js">
-<title>Support for NPM Scopes</title>
-<simpara>NPM supports a namespace concept for npm packages. Such namespaces are called "scopes". For details see
-<link xl:href="https://docs.npmjs.com/misc/scope">https://docs.npmjs.com/misc/scope</link> and <link xl:href="https://docs.npmjs.com/getting-started/scoped-packages">https://docs.npmjs.com/getting-started/scoped-packages</link>.
-In N4JS, this is supported too.</simpara>
-<simpara>Terminology:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>A project’s <emphasis>plain project name</emphasis> is its name without mentioning the project’s scope (if any),
-e.g. <literal>myProject</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>A project’s <emphasis>scope name</emphasis> is the name of the npm scope a project resides in, including a leading <literal>@</literal>.
-E.g. <literal>@myScope</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>A project’s <emphasis>N4JS project name</emphasis> is its plain project name, prefixed by its scope name (if any),
-separated by a <literal>/</literal>. For unscoped projects, this is identical to the plain project name.
-E.g., <literal>myProject</literal> (if unscoped), <literal>@myScope/myProject</literal> (if scoped).</simpara>
-</listitem>
-<listitem>
-<simpara>A project’s <emphasis>Eclipse project name</emphasis> is an ancillary name used only within the Eclipse UI for
-the project in the workspace. It is equal to the N4JS project name, except that <literal>:</literal> instead of <literal>/</literal> is
-used as separator between the scope and plain project name.
-E.g., <literal>myProject</literal> (if unscoped), <literal>@myScope:myProject</literal> (if scoped).</simpara>
-</listitem>
-</orderedlist>
-<simpara>In case the intended meaning is apparent from the context, the "N4JS project name" can simply be referred to
-as "project name" (as is common practice in the context of npm).</simpara>
-<simpara>In N4JS, when importing from a module <literal>M</literal> contained in a scoped project <literal>@myScope/myProject</literal>, the import statement’s
-module specifier should have one of the following forms:</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>import * as N from "a/b/c/M";</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>import * as N from "@myScope/myProject/a/b/c/M";</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>import * as N from "@myScope/myProject";</literal> (if <literal>M</literal> is specified as main module in `myProject’s package.json)</simpara>
-</listitem>
-</itemizedlist>
-<simpara>Thus, the N4JS project name, which includes the scope name, is simply used in place of an ordinary, non-scoped
-project’s name. This is in line with conventions in Javascript.</simpara>
-<requirement xml:id="GH-1026">
-<title>General Constraints</title>
-<simpara>
-<anchor xml:id="Req-GH-1026" xreflabel="[Req-GH-1026]"/>
-<emphasis role="strong">Requirement: GH-1026:</emphasis>
-<link linkend="Req-GH-1026">General Constraints</link> (ver. 1)</simpara>
- <simpara>
-
-1. The name given in the package.json file (i.e. value of top-level property "name") must be equal to
- the project’s "N4JS project name", as defined above.
-2. The name of the project folder on disk (i.e. folder containing the package.json file) must be equal to
- the project’s "plain project name", as defined above.
-3. Iff the project is scoped, this project folder must have a parent folder with a name equal to
- the project’s "scope name", including the leading <literal>@</literal>.
-4. Within Eclipse, the name of of an N4JS project in the workspace UI must be equal to the project’s
- "Eclipse project name", as defined above.</simpara>
-</requirement>
-</section>
-<section xml:id="sec:N4JS-Type-Definitions">
-<title>N4JS Type Definitions</title>
-<simpara>N4JS projects can depend on ordinary JavaScript projects by including them in the package.json file.
-From there on, modules of those JavaScript projects can be imported when writing N4JS code.
-However, since JavaScript is untyped there will not be any type information for e.g. classes, functions
-of ordinary JavaScript projects unless this type information is provided by a type definition project.
-Type definition projects do only contain n4jsd files that reflect the classes and functions of a specific npm.
-To refer to a JavaScript npm, the term <emphasis>plain-JS project</emphasis> will be used.</simpara>
-<section xml:id="_specify-type-definition">
-<title>Specify Type Definition</title>
-<simpara>A type definition project is structured like a normal npm.
-The major difference is that it provides n4jsd files instead of js files.
-These n4jsd files are named like and located at the exact position in the file tree as their js-counterparts.
-This ensures the type definition module and the corresponding plain-JS module to have the same fully-qualified name.
-Besides the usual properties the package.json file usually needs to specify the following properties in the n4js section.</simpara>
-<formalpara>
-<title>Package.json: Important properties for type definition projects</title>
-<para>
-<screen>{
- "n4js": {
- "projectType": "definition"
- "definesPackage": "..."
- "mainModule": "..."
- }
-}</screen>
-</para>
-</formalpara>
-<simpara>The project type declares this project to be a type definition projects.
-Consequently, it has to also declare the name for which plain-JS project its type definitions are provided (using <literal>definesPackage</literal>).
-Lastly, the main module has to be specified since this information will not be taken from the package.json of the plain-JS project.</simpara>
-<simpara>A type definition project may only define a main module if the corresponding plain-JS project defines a main module. In this case,
-the main module of the type definition project may have a different fully-qualified name / module specifier (but should, of course,
-define the types provided by the plain-JS project’s main module). This is possible, because in client code the import of a main
-module will always look the same, no matter the main module’s fully-qualified name / module specifier.</simpara>
-</section>
-<section xml:id="_name-conventions">
-<title>Name Conventions</title>
-<simpara>A type definition package can have an arbitrary name and define an arbitrary npm package.
-This can be handy for testing purposes or just creating some temporary type definitions for a local package.
-However, we chose to use a convention to simplify finding the right type definition package for a specific plain-JS project.
-First, the scope <literal>@n4jsd</literal> and second the exact name of the plain-JS project is used.
-For instance, when a user wants to install type definitions for the plain-JS project <literal>express</literal>,
-our related type definitions are called <literal>@n4jsd/express</literal>.</simpara>
-</section>
-<section xml:id="_version-conventions">
-<title>Version Conventions</title>
-<simpara>Since the plain-JS project will evolve over time and publish different versions, the need arises to also
-publish the type definition project in different versions that reflect this evolution.
-In addition to the evolution of the plain-JS project, a new version of the type definition project can
-also become necessary in case a bug in the type definitions was found or in case the language of N4JS changes
-and the type definitions have to be adjusted accordingly.
-Effectively, this will lead to a situation where both the implementation and the type definition project have
-a version that are technically unrelated from an npm point of view, but still are somehow related to each other
-from a semantical point of view.
-To keep the distinct versioning of both of the projects manageable,
-we propose the following conventions to partially align the type definition project’s version to that of the plain-JS project.</simpara>
-<section xml:id="_define-a-new-type-definition-package">
-<title>Define a New Type Definition Package</title>
-<simpara>We use the following convention to compute the version of type definition packages.</simpara>
-<simpara>     Major<subscript>types</subscript>.Minor<subscript>types</subscript>.Patch<subscript>types</subscript> = Major<subscript>impl</subscript>.Minor<subscript>impl</subscript>.0</simpara>
-<simpara>     Major<subscript>types</subscript>.Minor<subscript>types</subscript>.Patch<subscript>types</subscript> = 3.3.0</simpara>
-<simpara>Let’s say that a new version of a type definition package called <emphasis>types</emphasis> should be created
-that defines types for an npm called <emphasis>impl</emphasis> of version Major<subscript>impl</subscript>.Minor<subscript>impl</subscript>.Patch<subscript>impl</subscript>.
-According to our convention, the major and minor version numbers of the type definition package
-should just be copied from the version of the <emphasis>impl</emphasis> package.
-However, the version patch number of <emphasis>types</emphasis> should not be taken from <emphasis>impl</emphasis>.
-Instead, the patch number of <emphasis>types</emphasis> starts with <emphasis>0</emphasis> and increases with every update of this type definition version.
-For instance when a bug was found in version Major<subscript>types</subscript>.Minor<subscript>types</subscript>.0, the definitions have been extended, or
-adjusted to new language features, only the patch number increases to e.g. Major<subscript>types</subscript>.Minor<subscript>types</subscript>.1.</simpara>
-</section>
-<section xml:id="_using-a-type-definition-package">
-<title>Using a Type Definition Package</title>
-<simpara>On the client side, a type definition package is listed among the dependency section.
-Here we use the following convention to specify the required version of a type definition package.</simpara>
-<simpara>"dependencies": {<?asciidoc-br?>
-     "@n4jsd/Types": "<=Major<subscript>impl</subscript>.Minor<subscript>impl</subscript>.*"<?asciidoc-br?>
-}</simpara>
-<simpara>"dependencies": {<?asciidoc-br?>
-     "express": "^3.3.3",<?asciidoc-br?>
-     "@n4jsd/express": "<=3.3.*"<?asciidoc-br?>
-}</simpara>
-<simpara>According to this convention, the major and minor version numbers of the implementation package are used,
-prepended with a smaller-equals and appended with an asterisk for the patch number.
-This also applies when the implementation version contains a tilde, a caret, etc., or is omitting a minor or patch number.
-In case a non SemVer version is given (e.g. <literal>latest</literal>, empty string, url, etc.)
-it is recommended to plain copy the non SemVer version when possible.</simpara>
-</section>
-<section xml:id="_rational">
-<title>Rational</title>
-<simpara>The rational behind this convention reflects the idea of semantic versioning:</simpara>
-<blockquote>
-<attribution>
-<link xl:href="https://www.semver.org">semver.org</link>
-</attribution>
-<simpara>Given a version number MAJOR.MINOR.PATCH, increment the:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>MAJOR version when you make incompatible API changes,</simpara>
-</listitem>
-<listitem>
-<simpara>MINOR version when you add functionality in a backwards-compatible manner, and</simpara>
-</listitem>
-<listitem>
-<simpara>PATCH version when you make backwards-compatible bug fixes.</simpara>
-</listitem>
-</itemizedlist>
-</blockquote>
-<simpara>Patch version increments are always backwards compatible according to SemVer.
-In addition also no further functionality is added since this would imply at least an increment of the minor version.
-Consequently, patch versions do not affect the interface or type information of an plain-JS project.
-This is why patch version number fully suffices to reflect bug fixes and language changes for a given major.minor version.</simpara>
-<simpara>On client side, we recommend to use a smaller-equals qualifier because most probably there will not be the exact version
-of a requested type definition project.
-Instead, only some major.minor versions will have a type definition counterpart.
-Using a smaller-equals qualifier will make sure that a client will always get the latest version of a requested plain-JS project version.
-In case a newer version of the plain-JS project was already published,
-this convention guarantees that a compatible version of the type definition project is installed.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_modules" role="language-n4js">
-<title>Modules</title>
-<simpara>Each N4JS source file defines a module in the sense of ECMAScript2015, [<link linkend="ECMA15a">ECMA15a(p.S14)</link>].
-This is the overall structure of a module, based on [<link linkend="ECMA15a">ECMA15a(p.S14)</link>].</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">Script: {Script}
- annotations+=ScriptAnnotation*
- scriptElements+=ScriptElement*;
-
-/*
- * The top level elements in a script are type declarations, exports, imports or statements
- */
-ScriptElement:
- AnnotatedScriptElement
- | N4ClassDeclaration<Yield=false>
- | N4InterfaceDeclaration<Yield=false>
- | N4EnumDeclaration<Yield=false>
- | ImportDeclaration
- | ExportDeclaration
- | RootStatement<Yield=false>
-;</programlisting>
-<simpara>Grammar and semantics of import statement is described in <xref linkend="_import-statement"/>; of export statement described in <xref linkend="_export-statement"/>.</simpara>
-<simpara>An import statement imports a variable declaration, function declaration, or N4 type declaration defined and exported by another module into the current
-module under the given alias (which is similar to the original name if no alias is defined).
-The name of the module is its project’s source folder’s relative path without any extension, see <xref linkend="_qualified-names"/> for details.</simpara>
-</section>
-<section xml:id="_api-and-implementation-component" role="language-n4js">
-<title>API and Implementation Component</title>
-<note>
-<simpara>the API/Implementation concept is not fully implemented at this time (see GH-1291).</simpara>
-</note>
-<simpara>Instead of providing an implementation, N4JS components may only define an API by way of one or more n4jsd files which is then implemented by separate implementation projects.
-For one such API project, several implementation projects may be provided.
-Client code using the API will always be bound to the API project only, i.e. only the API project will appear in the client project’s <literal>package.json</literal> file under <literal>dependencies</literal>.
-When launching the client code, the launcher will choose an appropriate implementation for each API project in the client code’s direct or indirect dependencies
-and transparently replace the API project by the implementation project.
-In other words, instead of the API project’s output folder, the implementation project’s output folder will be put on the class path.
-Static compile time validations ensure that the implementation projects comply to their corresponding API project.</simpara>
-<simpara>Note how this concept can be seen as an alternative way of providing the implementation for an n4jsd file: usually n4jsd files are used to define types
-that are implemented in plain JavaScript code or provided by the runtime; this concept allows for providing the implementation of an n4jsd file in form of ordinary N4JS code.</simpara>
-<simpara>At this time, the concept of API and implementation components is in a prototype phase and the tool support is limited.
-The goal is to gain experience from using the early prototype support and then refine the concept over time.</simpara>
-<simpara>Here is a summary of the most important details of this concept (they
-are all subject to discussion and change):</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Support for this concept, esp. validations, should not be built into the core language but rather implemented as a separate validation/analysis tool.</simpara>
-</listitem>
-<listitem>
-<simpara>Validation is currently provided in the form of a separate view: the API / Implementation compare view.</simpara>
-</listitem>
-<listitem>
-<simpara>A project that defines one or more other projects in its <literal>package.json</literal> file under <literal>implementedProjects</literal> (cf. <xref linkend="package-json-implementedProjects"/>) is called <emphasis>implementation project</emphasis>.
-A project that has another project pointing to itself via <literal>ImplementedProjects</literal> is called <emphasis>API project</emphasis>.
-Note that, at the moment, there is no explicit definition making a project an API project.</simpara>
-</listitem>
-<listitem>
-<simpara>An implementation project must define an implementation ID in its <literal>package.json</literal> file using the <literal>implementationId</literal> property in the <literal>n4js</literal> section (cf. <xref linkend="package-json-implementationId"/>).</simpara>
-</listitem>
-<listitem>
-<simpara>For each public or public@Internal classifier or enum in an API project, there must be a corresponding type with the same fully-qualified name of the same or higher visibility in the implementation project.
-For each member of such a type in the API, there must exist a corresponding, owned <emphasis>or</emphasis> inherited type-compatible member in the implementation type.</simpara>
-</listitem>
-<listitem>
-<simpara>Beyond type compatibility, formal parameters should have the same name on API and implementation side; however, different names are legal but should be highlighted by API / Implementation tool support as a (legal) change.</simpara>
-</listitem>
-<listitem>
-<simpara>Comments regarding the state of the API or implementation may be added to the JSDoc in the source code using the special tag @apiNote.
-API / Implementation tool support should extract and present this information to the user in an appropriate form.</simpara>
-</listitem>
-<listitem>
-<simpara>If an API class <literal>C</literal> implements an interface <literal>I</literal>, it has to explicitly (re-) declare all members of <literal>I</literal> similar to the implementation.
-This is necessary for abstract classes anyway in order to distinguish the implemented methods from the non-implemented ones.
-For concrete classes, we want all members in <literal>C</literal> in order to be complete and avoid problems when the interface is changed or <literal>C</literal> is made abstract.</simpara>
-</listitem>
-</itemizedlist>
-<section xml:id="_execution-of-api-and-implementation-components">
-<title>Execution of API and Implementation Components</title>
-<simpara>When launching an N4JS component <emphasis>C</emphasis> under runtime environment <link linkend="AC">RE</link>, the user may(!) provide an implementation ID <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mspace width="-0.167em"/><mi>I</mi><mspace width="-0.167em"/><mi>D</mi></math> to run.
-Then, for each API project <emphasis>A</emphasis> in the direct or indirect dependencies of <emphasis>C</emphasis> an implementation project is chosen as follows:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Collect all implementation projects for <emphasis>A</emphasis> (i.e. projects that specify <emphasis>A</emphasis> in their <literal>package.json</literal> file under <literal>implementedProjects</literal>).</simpara>
-</listitem>
-<listitem>
-<simpara>Remove implementation projects that cannot be run under runtime environment <link linkend="AC">RE</link>, using the same logic as for running ordinary N4JS components (this step is not implemented yet!).</simpara>
-</listitem>
-<listitem>
-<simpara>If there are no implementation projects left, show an error.</simpara>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mspace width="-0.167em"/><mi>I</mi><mspace width="-0.167em"/><mi>D</mi></math> is defined (i.e. user specified an implementation ID to run), then:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>If there is an implementation project left with implementation ID <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mspace width="-0.167em"/><mi>I</mi><mspace width="-0.167em"/><mi>D</mi></math>, use that.</simpara>
-</listitem>
-<listitem>
-<simpara>Otherwise, show an error.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-<listitem>
-<simpara>If <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>I</mi><mspace width="-0.167em"/><mi>I</mi><mspace width="-0.167em"/><mi>D</mi></math> is undefined, then</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>If there is exactly 1 implementation project left, use it.</simpara>
-</listitem>
-<listitem>
-<simpara>Otherwise, in UI mode prompt the user for a choice, in headless mode how an error.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-<simpara>Having found an implementation project <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>n</mi></msub></math> for each API project <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>A</mi><mi>n</mi></msub></math>, launch as usual except that whenever <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>A</mi><mi>n</mi></msub></math>’s output folder would be used, use <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>n</mi></msub></math>’s
-output folder (esp. when constructing a <literal>class path</literal>) and when loading or importing a type from <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>A</mi><mi>n</mi></msub></math> return the corresponding type with the same fully-qualified name from <math xmlns="http://www.w3.org/1998/Math/MathML"><msub><mi>I</mi><mi>n</mi></msub></math>.</simpara>
-</section>
-<section xml:id="_api-and-implementation-with-di" role="language-n4js">
-<title>API and Implementation With DI</title>
-<simpara>API projects may use N4JS DI (<xref linkend="_dependency-injection"/>) language features which require Implementation projects to provide DI-compatible behaviour
-in order to allow a Client (implemented against an API project) to be executed with a given Implementation project.
-This is essential for normal execution and for test execution.</simpara>
-<simpara><xref linkend="diag_APITestsDI_Overview"/> shows some of those considerations from test client point of view.</simpara>
-<figure xml:id="diag_APITestsDI_Overview">
-<title>Overview of API tests with DI</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/12_components/fig/diag_ApiTestsDI_Overview.svg"/>
-</imageobject>
-<textobject><phrase>diag ApiTestsDI Overview</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Static DI mechanisms in N4JS allow an API project to enforce Implementation projects to provide all necessary information.
-This allows clients to work seamlessly with various implementations without specific knowledge about them or without relying on extra tools for proper project wiring.</simpara>
-<simpara><xref linkend="diag_ApiTestsDI_StaticDI"/> shows how API project defines project wiring and enforces certain level of testability.</simpara>
-<figure xml:id="diag_ApiTestsDI_StaticDI">
-<title>API tests with static DI</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/12_components/fig/diag_ApiTestsDI_StaticDI.svg"/>
-</imageobject>
-<textobject><phrase>diag ApiTestsDI StaticDI</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>During Client execution, weather it is test execution or not, N4JS mechanisms will replace the API project with a proper Implementation project.
-During runtime DI mechanisms will take care of providing proper instances of implantation types.</simpara>
-<simpara><xref linkend="diag_ApiTestsDI_Views"/> shows Types View perspective of the client, and Instances View perspective of the client.</simpara>
-<figure xml:id="diag_ApiTestsDI_Views">
-<title>Types view and Instances view</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/12_components/fig/diag_ApiTestsDI_Views.svg" width="80%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>diag ApiTestsDI Views</phrase></textobject>
-</mediaobject>
-</figure>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_plainjs">
-<title>PlainJS</title>
-<simpara>Since N4JS is a super set of JavaScript, is it both possible to use plain JavaScript in N4JS and vice versa.
-There may be some obstacles due to concepts introduced by N4JS to make code more maintainable and robust:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>N4JS’ static type system may complain about some older JavaScript hacks. Declared types, in particular, are assumed to be implicitly frozen.</simpara>
-</listitem>
-<listitem>
-<simpara>In N4JS, modules are used as namespaces with explicit export and import statements.
-The notion of globals is not directly supported by N4JS as this leads to unexpected side effects (several components providing and thus overriding global definitions, for example).</simpara>
-</listitem>
-<listitem>
-<simpara>N4JS defines a (ECMAScript 6 compatible) concept of object-oriented programming which may conflict with other plain JavaScript solutions.</simpara>
-</listitem>
-</orderedlist>
-<simpara>To overcome these problems, N4JS provides a couple of techniques summarized in this chapter.</simpara>
-<section xml:id="_type-inference-and-validation-for-plain-js" role="language-n4js">
-<title>Type Inference and Validation for Plain JS</title>
-<simpara>In plain JavaScript mode:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>All declared variables are inferred to <literal>any+</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>All declared functions return and accept a variadic number of arguments of type <literal>any+</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>It is allowed to use the <literal>return</literal> statement with or without an expression.</simpara>
-</listitem>
-<listitem>
-<simpara>New expressions with a receiver of <literal>any+</literal> is allowed.</simpara>
-</listitem>
-<listitem>
-<simpara>No type arguments are required for generic built-in types.</simpara>
-</listitem>
-<listitem>
-<simpara>Assigning a value to a read-only variable is not checked.</simpara>
-</listitem>
-<listitem>
-<simpara>Undeclared variables are treated as <literal>any+</literal> as well.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Note that this essentially disables all validation particularly since methods such as the ’import’-like function <literal>require</literal> are unknown.</simpara>
-</section>
-<section xml:id="_external-declarations" role="language-n4js">
-<title>External Declarations</title>
-<simpara>N4JS supports declaring external classes as a means to declare classes whose implementation is not N4JS so they can be used from N4JS.
-Together with structural typing, this allows N4JS to seamlessly integrate frameworks and libraries which have not been implemented in N4JS but in plain ECMAScript or another language.</simpara>
-<requirement xml:id="IDE-163">
-<title>External allowed occurrences</title>
-<simpara>
-<anchor xml:id="Req-IDE-163" xreflabel="[Req-IDE-163]"/>
-<emphasis role="strong">Requirement: IDE-163:</emphasis>
-<link linkend="Req-IDE-163">External allowed occurrences</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<itemizedlist>
-<listitem>
-<simpara>Declarations with external flags are only allowed in files with the extension <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mn>4</mn><mi>j</mi><mi>s</mi><mi>d</mi></math> (so called N4JS definition files).</simpara>
-</listitem>
-<listitem>
-<simpara>Only external classes, external interfaces marked with <literal>@N4JS</literal>, external enums, external function declarations and structurally typed interfaces are allowed in a <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mn>4</mn><mi>j</mi><mi>s</mi><mi>d</mi></math> file.</simpara>
-</listitem>
-<listitem>
-<simpara>Declarations with external flags are allowed to subclass built-in type <literal>Error</literal> type and all of its descendants such as
-<literal>EvalError</literal>, <literal>RangeError</literal>, <literal>ReferenceError</literal>, <literal>SyntaxError</literal>, <literal>TypeError</literal> and <literal>URIError</literal>, although any of the error types are annotated with <literal>@N4JS</literal>.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>The following explanations apply to all external declarations except
-where stated otherwise.</simpara>
-<simpara>In general, an external declaration uses the same syntax as the declaration of a normal N4JS declaration with the addition of the modifier <literal>external</literal>.</simpara>
-<simpara>External classifiers are always ’entirely external’ in that it is not possible to combine defined methods and external methods within a single class or interface.</simpara>
-</requirement>
-<requirement xml:id="IDE-164">
-<title>External classes inheritance</title>
-<simpara>
-<anchor xml:id="Req-IDE-164" xreflabel="[Req-IDE-164]"/>
-<emphasis role="strong">Requirement: IDE-164:</emphasis>
-<link linkend="Req-IDE-164">External classes inheritance</link> (ver. 1)</simpara>
- <simpara>
-
-1. An external class <emphasis>without</emphasis> the <literal>@N4JS</literal> annotation can only inherit from another external class or from one of the built-in ECMAScript types (e.g. Object).
-That is, by default external classes are derived from <literal>Object</literal>.
-2. An external class <emphasis>with</emphasis> the annotation <literal>@N4JS</literal> can only inherit from another external class annotated with <literal>@N4JS</literal> or from non-external N4JS classes.</simpara>
-</requirement>
-<requirement xml:id="IDE-165">
-<title>Structurally typed interface implementation</title>
-<simpara>
-<anchor xml:id="Req-IDE-165" xreflabel="[Req-IDE-165]"/>
-<emphasis role="strong">Requirement: IDE-165:</emphasis>
-<link linkend="Req-IDE-165">Structurally typed interface implementation</link> (ver. 1)</simpara>
- <simpara>
-
-1. An external class <emphasis>without</emphasis> the annotation <literal>@N4JS</literal> can only be implemented by structurally typed interfaces.
-2. An external class <emphasis>with</emphasis> the annotation <literal>@N4JS</literal> can only be implemented by structurally typed interfaces annotated with <literal>@N4JS</literal>.
-3. An external interface <emphasis>without</emphasis> the annotation <literal>@N4JS</literal> must be defined structurally.</simpara>
-</requirement>
-<requirement xml:id="IDE-166">
-<title>External interface inheritance</title>
-<simpara>
-<anchor xml:id="Req-IDE-166" xreflabel="[Req-IDE-166]"/>
-<emphasis role="strong">Requirement: IDE-166:</emphasis>
-<link linkend="Req-IDE-166">External interface inheritance</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>An interface in a n4jsd file <emphasis>without</emphasis> the annotation <literal>@N4JS</literal> can only inherit from another interface within a n4jsd file.</simpara>
-</listitem>
-<listitem>
-<simpara>An interface <emphasis>with</emphasis> the <literal>@N4JS</literal> annotation can only inherit from another interface annotated with <literal>@N4JS</literal>.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<requirement xml:id="IDE-167">
-<title>External class/interface members</title>
-<simpara>
-<anchor xml:id="Req-IDE-167" xreflabel="[Req-IDE-167]"/>
-<emphasis role="strong">Requirement: IDE-167:</emphasis>
-<link linkend="Req-IDE-167">External class/interface members</link> (ver. 1)</simpara>
- <simpara>
-
-1. The static and instance methods, getters and setters of an external class must not have a method body.
-2. The static and instance fields of an external class must not have an initializer.
-3. The constructor of an external class without the annotation <literal>@N4JS</literal> must not be declared private.
-4. Methods in interfaces with default implementation which cannot be expressed in the definition file must be annotated with <literal>@ProvidesDefaultImplementation</literal>.
-This is only allowed in interfaces annotated with <literal>@N4JS</literal>.
-5. Fields in interfaces or classes with initializers which cannot be expressed in the definition file, must be annotated with <literal>@ProvidesInitializer</literal>.
-This is only allowed in classes or interfaces annotated with <literal>@N4JS</literal>.</simpara>
-<simpara>This means that in external classes, all members except constructors may be declared private even if the class is not annotated with <literal>@N4JS</literal>. In interfaces, however, private members are disallowed anyway,
-cf. <xref linkend="Req-IDE-48"/>.</simpara>
-</requirement>
-<requirement xml:id="IDE-168">
-<title>Other external declarations</title>
-<simpara>
-<anchor xml:id="Req-IDE-168" xreflabel="[Req-IDE-168]"/>
-<emphasis role="strong">Requirement: IDE-168:</emphasis>
-<link linkend="Req-IDE-168">Other external declarations</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The literals of an external enum must not have a value.</simpara>
-</listitem>
-<listitem>
-<simpara>An external function declaration must not have a body.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<section xml:id="_declaring-externals">
-<title>Declaring externals</title>
-<simpara>By default, the implicit supertype of an external class is Object.
-If the <literal>@N4JS</literal> annotation is provided it is N4Object.
-If a superclass is explicitly given, the constraints from the previous section apply.</simpara>
-</section>
-<section xml:id="_instantiating-external-classes">
-<title>Instantiating external classes</title>
-<simpara>In most cases, it is desirable to instantiate external classes from external projects.
-Publicly exporting the class definition and providing a public constructor is good practice.</simpara>
-<simpara>In some cases, the instantiation from an outer scope is not wanted.
-A possible approach is to use a structurally typed interface instead of a class to link to the implementation.</simpara>
-<simpara>In case of API-definitions (see <xref linkend="_api-and-implementation-components"/>), it might be useful to limit the visibility of classes to narrower scopes such as package or private.</simpara>
-<simpara>External declarations can be instantiated if the following three requirements are fulfilled (not a constraint!):</simpara>
-<itemizedlist>
-<listitem>
-<simpara>External declarations have to be exported and be marked as public so they are accessible from outside.</simpara>
-</listitem>
-<listitem>
-<simpara>The contained or inherited constructor of an external class must be public.</simpara>
-</listitem>
-<listitem>
-<simpara>The external class must be linked to an implementation module (see below <xref linkend="_implementation-of-external-declarations"/>).</simpara>
-</listitem>
-</itemizedlist>
-</section>
-<section xml:id="_implementation-of-external-declarations">
-<title>Implementation of External Declarations</title>
-<simpara>All external declarations must be associated with an external implementation module in one way or another.
-Any time the external declaration is imported, the compiler generates code that imports the corresponding implementation module at runtime.</simpara>
-<simpara>There are two possible ways of linking an external declaration to its corresponding implementation:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>By naming convention defined in the <literal>package.json</literal> file.</simpara>
-</listitem>
-<listitem>
-<simpara>By declaring that the implementation is provided by the JavaScript runtime, see <xref linkend="_runtime-definitions"/> for details.</simpara>
-</listitem>
-</orderedlist>
-<simpara>The naming convention is based on the <literal>external</literal> source fragments defined in the <literal>package.json</literal> file (<xref linkend="package-json"/>).
-If the implementation is provided by the runtime directly, then this can be also specified in the <literal>package.json</literal> file by a module filter.</simpara>
-<simpara>The implicit link via the naming convention is used to link an external class declaration to its non-N4JS implementation module.
-It does not effect validation, but only compilation and runtime.
-Essentially, this makes the compiler generate code so that at runtime, the linked implementation module is imported instead of the declaration module.</simpara>
-<simpara>In most use cases of external declarations you also want to disable validation and module wrapping by specifying appropriate filters in the <literal>package.json</literal> file.</simpara>
-<simpara>Occasionally it is not possible for the validation to correctly detect a corresponding implementation element.
-For that reason, it is possible to disable validation of implementations completely via <literal>@@IgnoreImplementation</literal>.</simpara>
-<requirement xml:id="IDE-169">
-<title>Implementation of External Declarations</title>
-<simpara>
-<anchor xml:id="Req-IDE-169" xreflabel="[Req-IDE-169]"/>
-<emphasis role="strong">Requirement: IDE-169:</emphasis>
-<link linkend="Req-IDE-169">Implementation of External Declarations</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For a given external declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math> but not for
-API-definitions <footnote><simpara><xref linkend="_api-and-implementation-components"/></simpara></footnote>, the
-following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>If the declaration is neither provided by runtime nor validation of implementation is disabled,
-a corresponding implementation must be found by the naming convention.
-If no such implementation is found, a warning is generated.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-<example xml:id="external-definitions-and-implementations">
-<title>External Definitions and Their Implementations</title>
-<simpara>If, in addition to standard <literal>source</literal>, the <literal>source-external</literal> fragment is provided in <literal>Sources</literal>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mn>4</mn><mi>j</mi><mi>s</mi><mi>d</mi></math> files in the folder tree below source folders
-will be related to modules of the same name in the external folders. This is shown in <xref linkend="fig-external-class-naming"/>.</simpara>
-<figure xml:id="fig-external-class-naming">
-<title>External Class Implementation, Naming Convention</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/13_plainJS/fig/externalClassImplementation_naming.svg" width="60%" scalefit="1" align="center"/>
-</imageobject>
-<textobject><phrase>externalClassImplementation naming</phrase></textobject>
-</mediaobject>
-</figure>
-</example>
-</section>
-<section xml:id="_example">
-<title>Example</title>
-<simpara>Assume the following non-N4JS module:</simpara>
-<example xml:id="ex:External_Classes_Example">
-<title>External Classes</title>
-<programlisting language="javascript" linenumbering="unnumbered">module.exports = {
- "Point": function Point(x, y) {
- this.x = x;
- this.y = y;
- },
-
- "Circle": function Circle(center, radius) {
- this.center = center;
- this.radius = radius;
- this.scaleX = function(x){ this.x = x; }
- this.scaleY= function(y){ this.y = y; }
- }
-}</programlisting>
-<simpara>Assuming</simpara>
-<itemizedlist>
-<listitem>
-<simpara><literal>shapes.js</literal> is placed in project folder <emphasis role="strong">/external/a/b/shapes.js</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara><literal>shapes.n4jsd</literal> is placed in project folder <emphasis role="strong">/src/a/b/shapes.n4jsd</emphasis></simpara>
-</listitem>
-<listitem>
-<simpara><literal>package.json</literal> defines <emphasis role="strong">src</emphasis> as source folder and <emphasis role="strong">external</emphasis> as external source folder</simpara>
-</listitem>
-</itemizedlist>
-<simpara>the following N4JS external class declarations in <emphasis role="strong">shapes.n4jsd</emphasis> are sufficient:</simpara>
-<programlisting language="javascript" linenumbering="unnumbered">export external public class Point {
- x: number; y: number;
- constructor(x: number, y: number);
-}
-
-export external public class Circle {
- center: Point; radius: number;
- constructor(center: Point, radius: number);
-}</programlisting>
-<simpara>Note that the class and interface names in n4jsd files must match those in the js files, respectively.</simpara>
-</example>
-<example>
-<title>Structurally-typed external interfaces</title>
-<programlisting language="javascript" linenumbering="unnumbered">export external public interface ~Scalable {
- scaleX(factor: number);
- scaleY(factor: number);
-}
-
-export external public class Circle implements Scalable {
- center: Point;
- radius: number; x: number; y: number;
-
- @Override public scaleX(factor: number);
- @Override public scaleY(factor: number);
-
- constructor(center: Point, radius: number);
-}</programlisting>
-</example>
-</section>
-</section>
-<section xml:id="_global-definitions" role="language-n4js">
-<title>Global Definitions</title>
-<simpara>Existing JavaScript libraries and built-in objects provided by certain JavaScript environments often globally define variables.
-Although it is not recommended to use global definitions, this cannot always be avoided.</simpara>
-<simpara>N4JS supports global definitions via the annotation <literal>Global</literal>.
-This annotation can only be defined on modules (via <literal>@@Global</literal>) – this means that all declarations in the module are
-globally defined.<footnote><simpara>Global basically means that the module defines no namespace on its own. Thus the annotation is a script/module related annotation.</simpara></footnote></simpara>
-<simpara>We introduce a new pseudo property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>g</mi><mi>l</mi><mi>o</mi><mi>b</mi><mi>a</mi><mi>l</mi></math> on all declared elements accordingly:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>@Global</literal> </term>
-<listitem>
-<simpara>Boolean flag set to true if annotation <literal>@Global</literal> is set in containing module. The flag indicates that the exported element is globally available and must not be imported.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Since definition of global elements is not supported by N4JS directly, this can be only used in external definitions.
-A declaration with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>g</mi><mi>l</mi><mi>o</mi><mi>b</mi><mi>a</mi><mi>l</mi></math> can be used without explicit import statement. It is not possible to import these declarations.</simpara>
-<requirement xml:id="IDE-170">
-<title>Global Definitions</title>
-<simpara>
-<anchor xml:id="Req-IDE-170" xreflabel="[Req-IDE-170]"/>
-<emphasis role="strong">Requirement: IDE-170:</emphasis>
-<link linkend="Req-IDE-170">Global Definitions</link> (ver. 1)</simpara>
- <simpara>
-
-Global Definitions</simpara>
-<simpara>For a declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi><mo>.</mo><mi>g</mi><mi>l</mi><mi>o</mi><mi>b</mi><mi>a</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>, not a polyfill (<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mi>D</mi><mo>.</mo><mi>p</mi><mi>o</mi><mi>l</mi><mi>y</mi><mi>f</mi><mi>i</mi><mi>l</mi><mi>l</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>false</mtext></mstyle><mo>)</mo></mrow></math>, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The name of the definition must not be equal to any primitive type (<literal>string</literal>, <literal>number</literal> etc.), <literal>any</literal>, or an built-in N4 type (<literal>N4Object</literal> etc.).</simpara>
-</listitem>
-<listitem>
-<simpara>If the name of the definition equals a basic runtime time Object Type then the project must be a runtime environment:</simpara>
-</listitem>
-</orderedlist>
-<simpara><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><mo>∈</mo><mrow><mo>{</mo></mrow></math>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mspace width="3.0em"/><mi>'</mi></msup><mi>O</mi><mi>b</mi><mi>j</mi><mi>e</mi><mi>c</mi><msup><mi>t</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><msup><mi>n</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>A</mi><mi>r</mi><mi>r</mi><mi>a</mi><msup><mi>y</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>S</mi><mi>t</mi><mi>r</mi><mi>i</mi><mi>n</mi><msup><mi>g</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>B</mi><mi>o</mi><mi>o</mi><mi>l</mi><mi>e</mi><mi>a</mi><msup><mi>n</mi><mi>'</mi></msup></math>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><msup><mspace width="3.0em"/><mi>'</mi></msup><mi>N</mi><mi>u</mi><mi>m</mi><mi>b</mi><mi>e</mi><msup><mi>r</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>M</mi><mi>a</mi><mi>t</mi><msup><mi>h</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>D</mi><mi>a</mi><mi>t</mi><msup><mi>e</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>R</mi><mi>e</mi><mi>g</mi><mi>E</mi><mi>x</mi><msup><mi>p</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>E</mi><mi>r</mi><mi>r</mi><mi>o</mi><msup><mi>r</mi><mi>'</mi></msup><msup><mo>,</mo><mi>'</mi></msup><mi>J</mi><mi>S</mi><mi>O</mi><msup><mi>N</mi><mi>'</mi></msup></math>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>}</mo></mrow></math>
-<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>⇒</mo><mi>D</mi><mo>.</mo><mi>c</mi><mi>o</mi><mi>n</mi><mi>t</mi><mi>a</mi><mi>i</mi><mi>n</mi><mi>i</mi><mi>n</mi><mi>g</mi><mi>P</mi><mi>r</mi><mi>o</mi><mi>j</mi><mi>e</mi><mi>c</mi><mi>t</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>runtimeEnvironment</mtext></mstyle></math></simpara>
-</requirement>
-</section>
-<section xml:id="_runtime-definitions" role="language-n4js">
-<title>Runtime Definitions</title>
-<simpara>Some elements are predefined by the JavaScript runtime such as DOM elements by the browser or built-in ECMAScript or non-standard objects.
-These elements can be defined by means of external definitions; however, no actual implementation can be provided as these elements are actually provided by the runtime itself.</simpara>
-<simpara>Since these cases are rather rare and in order to enable additional checks such as verification that a given runtime actually provides the elements,
-this kind of element can only be defined in components of type runtime environment or runtime library (cf <xref linkend="_runtime-environment-and-runtime-libraries"/>).</simpara>
-<simpara>N4JS supports runtime definitions via the annotation <literal>@ProvidedByRuntime</literal>.
-This annotation can be defined</simpara>
-<itemizedlist>
-<listitem>
-<simpara>on modules (via <literal>@@ProvidedByRuntime</literal>)– this means that all declarations in the module are provided by the runtime</simpara>
-</listitem>
-<listitem>
-<simpara>on export statements or declarations.</simpara>
-</listitem>
-</itemizedlist>
-<simpara>We introduce a new pseudo property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>p</mi><mi>r</mi><mi>o</mi><mi>v</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>d</mi><mi>B</mi><mi>y</mi><mi>R</mi><mi>u</mi><mi>n</mi><mi>t</mi><mi>i</mi><mi>m</mi><mi>e</mi></math> accordingly:</simpara>
-<variablelist>
-<varlistentry>
-<term><literal>@ProvidedByRuntime</literal> </term>
-<listitem>
-<simpara>Boolean flag set to true if the annotation <literal>@ProvidedByRuntime</literal> is set.
-Flag indicates that the element is only declared in the module but its implementation is provided by the runtime.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<simpara>Since built-in types are usually defined globally, the annotation <literal>@ProvidedByRuntime</literal> is usually used in combination with <literal>@Global</literal>.</simpara>
-<requirement xml:id="IDE-171">
-<title>Provided By Runtime</title>
-<simpara>
-<anchor xml:id="Req-IDE-171" xreflabel="[Req-IDE-171]"/>
-<emphasis role="strong">Requirement: IDE-171:</emphasis>
-<link linkend="Req-IDE-171">Provided By Runtime</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>For a declaration <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi></math> with <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>D</mi><mo>.</mo><mi>p</mi><mi>r</mi><mi>o</mi><mi>v</mi><mi>i</mi><mi>d</mi><mi>e</mi><mi>d</mi><mi>B</mi><mi>y</mi><mi>R</mi><mi>u</mi><mi>n</mi><mi>t</mi><mi>i</mi><mi>m</mi><mi>e</mi><mo>=</mo><mstyle mathvariant="monospace"><mtext>true</mtext></mstyle></math>, the following constraints must hold:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>The declaration must either be an export declaration itself or an exportable declaration.</simpara>
-</listitem>
-<listitem>
-<simpara>The declaration must be contained in a definition module.</simpara>
-</listitem>
-<listitem>
-<simpara>The declaration must be (indirectly) contained in a component of type <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>runtimeEnvironment</mtext></mstyle></math> or <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>runtimeLibrary</mtext></mstyle></math>.</simpara>
-</listitem>
-<listitem>
-<simpara>There must be no implementation file with the same name as the definition module if annotation is defined for a whole module.</simpara>
-</listitem>
-</orderedlist>
-</requirement>
-</section>
-<section xml:id="_applying-polyfills" role="language-n4js">
-<title>Applying Polyfills</title>
-<simpara>(Runtime) Libraries often do not provide completely new types but modify existing types.
-The ECMA-402 Internationalization Standard [<link linkend="ECMA12a">ECMA12a</link>], for example, changes methods of the built-in class <literal>Date</literal> to be timezone-aware.
-Other scenarios include new functionality provided by browsers which are not part of an official standard yet.
-Even ECMAScript 6 [<link linkend="ECMA15a">ECMA15a</link>] extends the predecessor [<link linkend="ECMA11a">ECMA11a</link>] in terms of new methods or new method parameters added to existing types.
-It also adds completely new classes and features, of course.</simpara>
-<simpara>The syntax of runtime polyfills is described in section <xref linkend="_polyfill-definitions"/>.
-Here, an example of applying a runtime polyfill is detailed.</simpara>
-<example>
-<title>Object.observe with Polyfill</title>
-<simpara>The following snippet demonstrates how to define a polyfill of the built-in class <literal>Object</literal> to add the new ECMAScript 7 observer functionality.
-This snippet has to be defined in a runtime library or environment.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">@@ProvidedByRuntime
-@@Global
-
-@Polyfill
-export external public class Object extends Object {
- public static Object observe(Object object, Function callback, Array<string>? accept);
-
-}</programlisting>
-<simpara>A client referring to this runtime library (or environment) can now access the observer methods as if it were defined directly in the original declaration of <literal>Object</literal>.</simpara>
-</example>
-</section>
-</chapter>
-<chapter xml:id="_jsdoc-2">
-<title>JSDoc</title>
-<simpara role="language-n4js">In N4JS, comments starting with two asterisks (in <literal>/** .. */</literal>) are interpreted as
-documentation comments. The format is similar to JavaDoc or Google
-Closure annotations.</simpara>
-<section xml:id="_general-n4jsdoc-features" role="language-n4js">
-<title>General N4JSDoc Features</title>
-<simpara>We distinguish between line and inline tags.
-The format of the content of a tag is specific to the tag.
-Most line tags, however, contain a description which is simply multiline text with nested inline tags.
-Every comment may start with a description.</simpara>
-<section xml:id="_provided-inline-tags">
-<title>Provided Inline Tags</title>
-<section xml:id="jsdoc_tag__code">
-<title>@code</title>
-<simpara>Small code snippet, not validated yet.</simpara>
-</section>
-<section xml:id="jsdoc_tag__link">
-<title>@link</title>
-<simpara>Link to a type of element, not validated or supported in navigation yet.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_n4jsdoc-for-user-projects" role="language-n4js">
-<title>N4JSdoc for User Projects</title>
-<section xml:id="_standard-tags">
-<title>Standard Tags</title>
-<section xml:id="_-author">
-<title>@author</title>
-<simpara>Name of author, repeat for multiple authors. Name of author is not
-validated.</simpara>
-</section>
-<section xml:id="jsdoc_tag_param">
-<title>@param</title>
-<simpara>Parameter description, not validated at the moment.</simpara>
-</section>
-<section xml:id="jsdoc_tag_return">
-<title>@return</title>
-<simpara>Return description, not validated at the moment.</simpara>
-</section>
-</section>
-<section xml:id="_test-related-tags">
-<title>Test Related Tags</title>
-<simpara>The following tags are supposed to be used only in tests.</simpara>
-<section xml:id="jsdoc_tag__testee">
-<title>@testee</title>
-<simpara>Link to type (maybe a function) or member tested by the test.</simpara>
-<requirement xml:id="IDE-172">
-<title>@testee Semantics</title>
-<simpara>
-<anchor xml:id="Req-IDE-172" xreflabel="[Req-IDE-172]"/>
-<emphasis role="strong">Requirement: IDE-172:</emphasis>
-<link linkend="Req-IDE-172">@testee Semantics</link> (ver. 1)</simpara>
- <simpara>
-
-. Tag can be only used on either
-.. methods annotated with <literal>@Test</literal>
-.. classes in test projects or folders, cf. <xref linkend="jsdoc_tag__testeeFromType"/>.
-. Tag requires a single argument, which is a fully qualified name to a type, including the module specifier.
-The format is as follows: <literal>moduleSpecifier '.' typeName ( ('.'|'#') memberName)?</literal>
-. Tag is <emphasis>not</emphasis> repeatable, that is a single test method (or class) can refer to only one testee.
-. Tag precedes the <literal>reqid</literal> tag, i.e., if a <literal>@testee</literal> is specified, the <literal>reqid</literal> will be ignored.</simpara>
-</requirement>
-<example>
-<title>@testee</title>
-<simpara>The target element is to be fully qualified including the module specifier. The module specifier is simply
-the source folder relative path name with forward slashes. Type and
-element are added to that using dot as a separator. For example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/**
- * @testee some/package/Module.Type.member
- */</programlisting>
-</example>
-</section>
-<section xml:id="jsdoc_tag__testeeFromType">
-<title>@testeeFromType</title>
-<simpara>Instead of directly linking a test method to a testee, the testee is to
-be derived from the linked testee of the test class. This is useful if a
-base test class is defined with generic tests, e.g., for testing methods
-defined in an interface and implemented by some classes. This base test
-class is then extended by concrete test classes, correctly setting up
-the test fixture, e.g., creating instances of some classes implementing
-the interfaces tested in the base class.</simpara>
-<example>
-<title>Usage of testeeFromType</title>
-<simpara>In the following example, the is used. This tag will lead to a test documentation for <literal>B.foo</literal> and <literal>C.foo</literal>.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">abstract class Base {
- /**
- * @testeeFromType
- */
- @Test testFoo() {..}
-}
-
-/**
- * @testee B.foo
- */
-class TestB extends Base {}
-
-/**
- * @testee C.foo
- */
-class TestC extends Base {}</programlisting>
-</example>
-<note>
-<simpara>The resulting spec has to be double-checked for consistency
-since it is easily possible that too many constraints are generated.</simpara>
-</note>
-</section>
-<section xml:id="_testeeType_and__testeeMember">
-<title>@testeeType and @testeeMember</title>
-<simpara>Specifying the testee at the test method directly should be sufficient
-for most cases. The <literal>@testeeFromType</literal> tag already provides support for some cases in which a base test class is reused by subtypes. This case usually only works if
-the base test class tests a single method only. If the base test class
-tests several methods and if a sub test class only provides a different
-fixture, this mechanism is not sufficient. For that purpose, the two
-tags <literal>@testeeFromType</literal> and <literal>@@testeeMember</literal> are to be used.
-They enable the separation of a test related to a specific member and the concrete receiver type of the tested member.</simpara>
-<simpara>The <literal>@testeeType</literal> is to defined in the test class JSDoc (actually, it is not
-recognized when defined in a member JSDoc). The <literal>@testeeMember</literal> is specified in the test method JSDoc. The "real" testee is then computed from the testee type and the testee method.</simpara>
-<note>
-<simpara>1. This only works for instance members, so far!<?asciidoc-br?>
-2. There is no validation for invalid combinations!</simpara>
-</note>
-<example xml:id="ex:testeetype-and-testeemethod">
-<title>testeeType and testeeMethod</title>
-<simpara>Assume the following testees:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">class A {
- foo(): void {..}
- bar(): void { .. this.foo(); ..}
-}
-class B extends A {
- @Override foo() { .. }
-}</programlisting>
-</example>
-<simpara>Assume that the tests have to ensure the same semantics for <literal>bar</literal>, which is
-maybe changed by a wrong implementation of <literal>foo</literal>. That is, <literal>bar</literal> is to be tested in
-case of the receiver type <literal>A</literal> and <literal>B</literal>. This can be achieved by the following
-tests:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/**
- * @testeeType A.A
- */
-class ATest {
- fixture(): A { return new A(); }
-
- /**
- * @testeeMember bar
- */
- @Test testBar(): void { assertBehavior( fixture().bar() ); }
-}
-/**
- * @testeeType B.B
- */
-class BTest extends ATest {
- @Override fixture(): B { return new B(); }
-}</programlisting>
-<simpara>This actually defines two tests, which is also recognized by the spec
-exporter:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>testBar</literal> for a receiver of type <literal>A</literal>:</simpara>
-<simpara><literal>ATest</literal>'s JSDoc <literal>@testeeType</literal> + <literal>ATest.testBar</literal>'s JSDoc <literal>@testeeMember</literal> = testee <literal>A.A.bar</literal></simpara>
-</listitem>
-<listitem>
-<simpara><literal>testBar</literal> for a receiver of type <literal>B</literal>:</simpara>
-<simpara><literal>BTest</literal>'s JSDoc <literal>@testeeType</literal> + <literal>ATest.testBar</literal>'s JSDoc <literal>@testeeMember</literal> = testee <literal>B.B.bar</literal></simpara>
-</listitem>
-</orderedlist>
-<note>
-<simpara>In all cases when <literal>@testeeFromType</literal> or <literal>@testeeType</literal>/<literal>@testeeMember</literal> is used, the resulting spec has to be
-double-checked for consistency. Consider if the multiplication of spec
-constraints is truly required, in particular if the original semantics
-of a method is not changed. Remember: It is possible to write API tests
-and omit the spec constraint generation simply by not adding the testee
-links.</simpara>
-</note>
-<example>
-<title>testeeType and testeeMethod with omitted constraints</title>
-<simpara>Assume testees similar as in <xref linkend="ex:testeetype-and-testeemethod"/>. Since the semantics of <literal>bar</literal> is not changed in <literal>B</literal>, it is probably not necessary to generate the same constraint in the documentation for <literal>bar</literal> twice (one in the section for class <literal>A</literal> and another one in the section of class <literal>B</literal>).
-Still, we want the test to be executed for both receivers. This is how it is achieved:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">abstract class BaseTest {
- abstract fixture(): A;
-
- /**
- * @testeeMember bar
- */
- @Test testBar(): void { assertBehavior( fixture().bar() ); }
-}
-
-/**
- * @testeeType A.A
- */
-class ATest extends BaseTest {
- fixture(): A { return new A(); }
-}
-
-class BTest extends BaseTest {
- @Override fixture(): B { return new B(); }
-}</programlisting>
-<simpara>This actually defines two tests as in the previous example. Only one
-constraint is created in the spec by the spec exporter:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara><literal>testBar</literal> for a receiver of type <literal>A</literal>:<?asciidoc-br?>
-<literal>ATest</literal>'s JSDoc <literal>@testeeType</literal> + <literal>BaseTest.testBar</literal>'s JSDoc <literal>@testeeMember</literal> = testee <literal>A.A.bar</literal></simpara>
-</listitem>
-</orderedlist>
-<simpara>Although a test for receiver of type <literal>B</literal> is run, no additional constraint is
-created since there is no <literal>@testeeType</literal> available neither in <literal>BTest</literal> nor in <literal>BaseTest</literal>.</simpara>
-</example>
-</section>
-<section xml:id="jsdoc_tag_reqid_in_Tests">
-<title>@reqid in Tests</title>
-<simpara>ID of feature used in <literal>JSDoc</literal> for the requirements section. If no
-testee (via one of the tags above) is given, then the test is linked to
-the requirement with given id.</simpara>
-</section>
-</section>
-</section>
-<section xml:id="_n4jsdoc-for-api-and-implementation-projects" role="language-n4js">
-<title>N4JSDoc for API and Implementation Projects</title>
-<simpara>The following tags are supposed to be used in API and implementation
-projects.</simpara>
-<section xml:id="jsdoc_tag__apiNote">
-<title>@apiNote</title>
-<simpara>Simple note that is shown in the API compare view.</simpara>
-</section>
-<section xml:id="API_Project_Tags">
-<title>API Project Tags</title>
-<simpara>The following tags are supposed to be used in API projects only.</simpara>
-<section xml:id="jsdoc_tag_apiState">
-<title>@apiState</title>
-<simpara>State of type or member definition, e.g., stable or draft. This can be
-used to define a history. In this case, the tag has to be repeated. For
-example:</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/**
- * @apiState stable (WK)
- * @apiState reviewed (JvP)
- */</programlisting>
-</section>
-</section>
-</section>
-</chapter>
-<chapter xml:id="_jsx">
-<title>JSX</title>
-<section xml:id="_jsx-support" role="language-jsx">
-<title>JSX Support</title>
-<simpara>N4JS scripts with file extension "n4jsx" support the special <link xl:href="https://facebook.github.io/jsx/">JSX syntax</link>. Files ending with "jsx" are considered as plain Javascript.</simpara>
-<requirement xml:id="IDE-241101">
-<title>React Component</title>
-<simpara>
-<anchor xml:id="Req-IDE-241101" xreflabel="[Req-IDE-241101]"/>
-<emphasis role="strong">Requirement: IDE-241101:</emphasis>
-<link linkend="Req-IDE-241101">React Component</link> (ver. 1)</simpara>
- <simpara>
-
-There are two ways of defining a React component:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>functional component: A function is a React component, iff</simpara>
-<itemizedlist>
-<listitem>
-<simpara>its return type is React.Element</simpara>
-</listitem>
-<listitem>
-<simpara>the function has at least one parameter. This first parameter is considered as the <literal>props</literal> property.
-The type of the first parameter only has public fields (or methods defined by Object).
-The fields may be defined as optional.</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-<listitem>
-<simpara>class component: A class is a React component, iff</simpara>
-<itemizedlist>
-<listitem>
-<simpara>it extends <literal>React.Component</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>the type parameters must be structural types.</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The first parameter defines the <literal>props</literal> type, it must only define public fields (or methods defined by Object)</simpara>
-</listitem>
-<listitem>
-<simpara>The second parameter defines the <literal>state</literal> type, it must only define public fields (or methods defined by Object)</simpara>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
-<simpara>In both cases, the name must be capitalized (i.e., start with an upper case letter).</simpara>
-</requirement>
-<simpara>Component must be written capitalized (i.e. first letter upper case), html (or other xml elements) must be written lower case.</simpara>
-<requirement xml:id="IDE-241102">
-<title>JSX Basic Syntax</title>
-<simpara>
-<anchor xml:id="Req-IDE-241102" xreflabel="[Req-IDE-241102]"/>
-<emphasis role="strong">Requirement: IDE-241102:</emphasis>
-<link linkend="Req-IDE-241102">JSX Basic Syntax</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<simpara>The following JSX syntax is supported (EBNF with model element assignments as used in Xtext). All other ECMAScript 2015 and N4JS syntax constructs are unaffected by this addition.</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">PrimaryExpression <Yield> returns n4js::Expression:
- ... // as in N4JS
- | JSXElement
-;
-
-JSXElement:
- '<' jsxElementName=JSXElementName JSXAttributes
- (('>' jsxChildren+=JSXChild* JSXClosingElement) | ('/' '>'));
-
-fragment JSXClosingElement *:
- '<' '/' jsxClosingName=JSXElementName '>';
-
-JSXChild:
- JSXElement | JSXExpression
-;
-
-JSXExpression: '{' expression=AssignmentExpression<false,false> '}';
-
-JSXElementName:
- expression=JSXElementNameExpression
- ;
-
-JSXElementNameExpression returns n4js::Expression:
- IdentifierRef<false>
- ({n4js::ParameterizedPropertyAccessExpression.target=current} ParameterizedPropertyAccessExpressionTail<false>)*
-;
-
-fragment JSXAttributes *:
- jsxAttributes+=JSXAttribute*;
-
-JSXAttribute:
- JSXSpreadAttribute
- |
- JSXPropertyAttribute;
-
-JSXSpreadAttribute:
- '{' '...' expression=AssignmentExpression<false,false> '}';
-
-JSXPropertyAttribute:
- property=[types::IdentifiableElement|IdentifierName] '=' (jsxAttributeValue=StringLiteral | ('{'
- jsxAttributeValue=AssignmentExpression<false,false> '}'));</programlisting>
-<simpara>This syntax is similar to the syntax defined by <link xl:href="https://facebook.github.io/jsx/">JSX</link>, except that</simpara>
-<itemizedlist>
-<listitem>
-<simpara>JSXNamedspaceName is not supported</simpara>
-</listitem>
-<listitem>
-<simpara>JSXText is not supported, instead, string template literals are to be used</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>Remarks on differences between the syntax defined in <xref linkend="Req-IDE-241102"/> and <link xl:href="https://facebook.github.io/jsx/">JSX</link>:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>JSXSelfClosingElement, JSXOpeningElement and JSXClosingElement are merged into one single rule JSXElement</simpara>
-</listitem>
-<listitem>
-<simpara>JSXAttributes is defined as fragment, that is, the attributes become fields of the JSXElement</simpara>
-</listitem>
-<listitem>
-<simpara>The different types of JSXElementName are defined by means of JSXElementNameExpression which is a simple expression, reusing the existing rules IdentifierRef and ParameterizedPropertyAccessExpression to model JSXIdentifer and JSXMemberExpression respectively</simpara>
-</listitem>
-<listitem>
-<simpara>JSXPropertyAttribute models the JSX non-spread JSXAttribute definition; again existing rules (IdentifierName, StringLiteral) are used to model JSX specific ones (JSXAttributeName, JSXDoubleStringCharacters, JSXSingleStringCharacters)</simpara>
-</listitem>
-</itemizedlist>
-<requirement xml:id="IDE-241401">
-<title>JSX Syntax With Free Text</title>
-<simpara>
-<anchor xml:id="Req-IDE-241401" xreflabel="[Req-IDE-241401]"/>
-<emphasis role="strong">Requirement: IDE-241401:</emphasis>
-<link linkend="Req-IDE-241401">JSX Syntax With Free Text</link> (ver. 1)</simpara>
- <simpara>
-</simpara>
-<programlisting language="xtext" linenumbering="unnumbered">JSXChild:
- JSXElement | JSXExpression | JSXText
-;</programlisting>
-</requirement>
-<requirement xml:id="IDE-241103">
-<title>JSX Extended Syntax Check</title>
-<simpara>
-<anchor xml:id="Req-IDE-241103" xreflabel="[Req-IDE-241103]"/>
-<emphasis role="strong">Requirement: IDE-241103:</emphasis>
-<link linkend="Req-IDE-241103">JSX Extended Syntax Check</link> (ver. 1)</simpara>
- <simpara>
-
-* It is an error, if corresponding opening and closing JSXElements have different names.</simpara>
-</requirement>
-<requirement xml:id="IDE-241113">
-<title>JSX Expression Type</title>
-<simpara>
-<anchor xml:id="Req-IDE-241113" xreflabel="[Req-IDE-241113]"/>
-<emphasis role="strong">Requirement: IDE-241113:</emphasis>
-<link linkend="Req-IDE-241113">JSX Expression Type</link> (ver. 1)</simpara>
- <simpara>
-
-The type of a JSX expression is React.Element.</simpara>
-</requirement>
-<requirement xml:id="IDE-241114">
-<title>React Symbol</title>
-<simpara>
-<anchor xml:id="Req-IDE-241114" xreflabel="[Req-IDE-241114]"/>
-<emphasis role="strong">Requirement: IDE-241114:</emphasis>
-<link linkend="Req-IDE-241114">React Symbol</link> (ver. 1)</simpara>
- <simpara>
-
-If a JSX literal is used, it is an error if the React symbol is not imported via</simpara>
-<programlisting language="jsx" linenumbering="unnumbered">import React from "react"</programlisting>
-</requirement>
-<requirement xml:id="IDE-241115">
-<title>JSXElement names (tags)</title>
-<simpara>
-<anchor xml:id="Req-IDE-241115" xreflabel="[Req-IDE-241115]"/>
-<emphasis role="strong">Requirement: IDE-241115:</emphasis>
-<link linkend="Req-IDE-241115">JSXElement names (tags)</link> (ver. 1)</simpara>
- <simpara>
-
-* It is an error if a capitalized tag cannot be bound to a function or class declaration.</simpara>
-</requirement>
-<requirement xml:id="IDE-241116">
-<title>JSXElements referring to React components</title>
-<simpara>
-<anchor xml:id="Req-IDE-241116" xreflabel="[Req-IDE-241116]"/>
-<emphasis role="strong">Requirement: IDE-241116:</emphasis>
-<link linkend="Req-IDE-241116">JSXElements referring to React components</link> (ver. 1)</simpara>
- <simpara>
-
-* It is an error, if a tag binds to a function declaration, which is not conform to the functional component definition.
-* It is an error, if a tag binds to a class declaration, which is not conform to the class component definition.</simpara>
-</requirement>
-<requirement xml:id="IDE-241117">
-<title>JSXAttributes and React component properties</title>
-<simpara>
-<anchor xml:id="Req-IDE-241117" xreflabel="[Req-IDE-241117]"/>
-<emphasis role="strong">Requirement: IDE-241117:</emphasis>
-<link linkend="Req-IDE-241117">JSXAttributes and React component properties</link> (ver. 1)</simpara>
- <simpara>
-
-If the tag binds to a component, the following constraints must hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The attribute must be a non-private field of the properties type.</simpara>
-</listitem>
-<listitem>
-<simpara>The tag should define attributes for all non-optional fields of the properties type. If no attribute is defined for a non-optional field, a warning is issued.</simpara>
-</listitem>
-<listitem>
-<simpara>The type of the attribute expression must be conform to the type of the corresponding <literal>props</literal>'s property</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-241118">
-<title>JSXElements referring to XML elements</title>
-<simpara>
-<anchor xml:id="Req-IDE-241118" xreflabel="[Req-IDE-241118]"/>
-<emphasis role="strong">Requirement: IDE-241118:</emphasis>
-<link linkend="Req-IDE-241118">JSXElements referring to XML elements</link> (ver. 1)</simpara>
- <simpara>
-
-If the lower-case tag does not bind to a function or class declaration, the following constraints must be hold:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>If the tag is neither a pre-defined HTML tag nor an SVG tag, a warning is issued.</simpara>
-</listitem>
-<listitem>
-<simpara>If an attribute of the tag is not a pre-defined property of the html tag or react specific attributes, a warning is issued. This requirement is currently NOT supported.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<requirement xml:id="IDE-241119">
-<title>JSXSpreadAttribute behavior</title>
-<simpara>
-<anchor xml:id="Req-IDE-241119" xreflabel="[Req-IDE-241119]"/>
-<emphasis role="strong">Requirement: IDE-241119:</emphasis>
-<link linkend="Req-IDE-241119">JSXSpreadAttribute behavior</link> (ver. 1)</simpara>
- <simpara>
-
-The use of spread operators within an JSX element for specifying multiple attributes should be allowed. In this case, all constraints regarding type conformity checking and non-optional properties mentioned in <xref linkend="Req-IDE-241117"/> apply to the attributes specified in the spread operator. In particular,</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The type of each attribute specified in spread operator must be conform to the type of the corresponding property of <literal>props</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>If a non-optional property of <literal>props</literal> is specified neither as attribute nor in a spread operator, a warning is issued.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-</section>
-<section xml:id="_jsx-backend">
-<title>JSX Backend</title>
-<simpara>The support for JSX in N4JS aims for an implementation that adheres to the idea of <link xl:href="https://reactjs.org/docs/jsx-in-depth.html">React JSX</link>. This means that JSX elements are transpiled to React Element factory calls (e.g. <literal><div prop="c">content</div></literal> transpiles to <literal>React.createElement('div', {prop: "c"}, null)</literal>). For that, the transpiler must be aware of a specific implementation of React and the corresponding <literal>createElement</literal> function.</simpara>
-<requirement xml:id="GH-687">
-<title>React Implementation</title>
-<simpara>
-<anchor xml:id="Req-GH-687" xreflabel="[Req-GH-687]"/>
-<emphasis role="strong">Requirement: GH-687:</emphasis>
-<link linkend="Req-GH-687">React Implementation</link> (ver. 1)</simpara>
- <simpara>
-
-A react implementation is given in terms of a module that fulfils the following properties:</simpara>
-<itemizedlist>
-<listitem>
-<simpara>The FQN of the module is <literal>react</literal>.</simpara>
-</listitem>
-<listitem>
-<simpara>Type definitions are available for the module.</simpara>
-</listitem>
-<listitem>
-<simpara>The module exports a function of name <literal>createElement</literal>.</simpara>
-</listitem>
-</itemizedlist>
-</requirement>
-<simpara>If a react implementation is declared as project dependency, the N4JS transpiler automatically imports it to the module using JSX and generates the corresponding factory calls.</simpara>
-</section>
-</chapter>
-<chapter xml:id="_grammars">
-<title>Grammars</title>
-<simpara>N4JS extends the ECMAScript 2015 language grammar and combines it with type expression.</simpara>
-<note>
-<simpara>These grammars are slightly simplified versions of the "real" Xtext grammars used in the implementation.
-These grammars are post-processed and combined with additional validators so not all constructs are necessarily available in N4JS.</simpara>
-</note>
-<section xml:id="_type-expressions-grammar">
-<title>Type Expressions Grammar</title>
-<formalpara xml:id="lst:EBNFTypeExpression">
-<title>EBNF Type Expression Grammar</title>
-<para>
-<programlisting language="xtext" linenumbering="unnumbered">TypeRef:
- TypeRefWithoutModifiers =>undefModifier=UndefModifierToken?
- | undefModifier=UndefModifierToken;
-
-TypeRefWithoutModifiers:
- ((ParameterizedTypeRef | ThisTypeRef) => dynamic?='+'?)
- | ConstructorTypeRef
- | ClassifierTypeRef
- | FunctionTypeExpression
- | UnionTypeExpression
- | IntersectionTypeExpression;
-
-TypeRefFunctionTypeExpression:
- ParameterizedTypeRef
- | ConstructorTypeRef
- | ClassifierTypeRef
- | UnionTypeExpression
- | IntersectionTypeExpression
- ;
-
-TypeRefForCast:
- ParameterizedTypeRef
- | ThisTypeRef
- | ConstructorTypeRef
- | ClassifierTypeRef
- | FunctionTypeExpression;
-
-TypeRefInClassifierType:
- ParameterizedTypeRefNominal
- | ThisTypeRefNominal;
-
-
-ThisTypeRef:
- ThisTypeRefNominal | ThisTypeRefStructural;
-
-ThisTypeRefNominal:
- 'this';
-
-ThisTypeRefStructural:
- definedTypingStrategy=TypingStrategyUseSiteOperator
- 'this'
- ('with' TStructMemberList)?;
-
-FunctionTypeExpression:
- '{'
- ('@' 'This' '(' declaredThisType=TypeRefFunctionTypeExpression ')')?
- 'function'
- ('<' ownedTypeVars+=TypeVariable (',' ownedTypeVars+=TypeVariable)* '>')?
- '(' TAnonymousFormalParameterList ')'
- (':' returnTypeRef=TypeRef)?
- '}';
-
-fragment TAnonymousFormalParameterList*:
- (fpars+=TAnonymousFormalParameter (',' fpars+=TAnonymousFormalParameter)*)?
-;
-
-TAnonymousFormalParameter:
- variadic?='...'? (=> name=TIdentifier ':')? typeRef=TypeRef
-;
-
-UnionTypeExpression:
- 'union' '{' typeRefs+=TypeRefWithoutModifiers (',' typeRefs+=TypeRefWithoutModifiers)* '}';
-
-IntersectionTypeExpression:
- 'intersection' '{' typeRefs+=TypeRefWithoutModifiers (',' typeRefs+=TypeRefWithoutModifiers)* '}';
-
-ParameterizedTypeRef:
- ParameterizedTypeRefNominal | ParameterizedTypeRefStructural;
-
-ParameterizedTypeRefStructural:
- definedTypingStrategy=TypingStrategyUseSiteOperator
- declaredType=[Type|TypeReferenceName]
- (=>'<' typeArgs+=TypeArgument (',' typeArgs+=TypeArgument)* '>')?
- ('with' TStructMemberList)?;
-
-fragment TStructMemberList*: '{' (astStructuralMembers+=TStructMember (';'|',')?)* '}';
-
-TStructMember:
- TStructGetter
- | TStructSetter
- | TStructMethod
- | TStructField;
-
-TStructMethod:
- =>
- (('<' typeVars+=TypeVariable (',' typeVars+=TypeVariable)* '>')?
- name=TypesIdentifier '('
- ) TAnonymousFormalParameterList ')'
- (':' returnTypeRef=TypeRef)?
-;
-
-TStructField:
- name=TypesIdentifier (':' typeRef=TypeRef)?
-;
-
-TStructGetter:
- => ('get'
- name=TypesIdentifier)
- '(' ')' (':' declaredTypeRef=TypeRef)?
-;
-
-TStructSetter:
- => ('set'
- name=TypesIdentifier)
- '(' fpar=TAnonymousFormalParameter ')'
-;
-
-ParameterizedTypeRefNominal:
- declaredType=[Type|TypeReferenceName]
- (=> '<' typeArgs+=TypeArgument (',' typeArgs+=TypeArgument)* '>')?;
-
-TypingStrategyUseSiteOperator:
- '~' ('~' | STRUCTMODSUFFIX)?;
-
-TypingStrategyDefSiteOperator:
- '~';
-
-terminal STRUCTMODSUFFIX:
- ('r' | 'i' | 'w') '~'
-;
-
-ConstructorTypeRef:
- 'constructor' '{' staticTypeRef=TypeRefInClassifierType '}';
-
-ClassifierTypeRef:
- 'type' '{' staticTypeRef=TypeRefInClassifierType '}';
-
-TypeReferenceName:
- IDENTIFIER ('.' IDENTIFIER)*;
-
-TypeArgument:
- Wildcard | TypeRef;
-
-Wildcard:
- => ('?') (('extends' declaredUpperBound=TypeRef) | ('super'
- declaredLowerBound=TypeRef))?;
-
-UndefModifierToken:
- '?';
-
-TypeVariable:
- name=IDENTIFIER ('extends' declaredUpperBounds+=ParameterizedTypeRef ('&'
- declaredUpperBounds+=ParameterizedTypeRef)*)?;
-
-TypesIdentifier:
- IDENTIFIER
- | 'get' | 'set' | 'abstract' | 'project'
- | 'union' | 'intersection'
- | 'as' | 'from' | 'type' | 'void' | 'null';
-
-TIdentifier:
- TypesIdentifier
- | 'implements' | 'interface'
- | 'private' | 'protected' | 'public'
- | 'static'
-;
-
-terminal IDENTIFIER:
- IDENTIFIER_START IDENTIFIER_PART*;
-
-terminal INT:
- DECIMAL_INTEGER_LITERAL_FRAGMENT;
-
-terminal ML_COMMENT:
- ML_COMMENT_FRAGMENT;
-
-terminal SL_COMMENT:
- '//' (!LINE_TERMINATOR_FRAGMENT)*;
-
-terminal EOL:
- LINE_TERMINATOR_SEQUENCE_FRAGMENT;
-
-terminal WS:
- WHITESPACE_FRAGMENT+;
-
-terminal fragment UNICODE_ESCAPE_FRAGMENT:
- '\\' ('u' (
- HEX_DIGIT (HEX_DIGIT (HEX_DIGIT HEX_DIGIT?)?)?
- | '{' HEX_DIGIT* '}'?
- )?)?;
-
-terminal fragment IDENTIFIER_START:
- UNICODE_LETTER_FRAGMENT
- | '$'
- | '_'
- | UNICODE_ESCAPE_FRAGMENT;
-
-terminal fragment IDENTIFIER_PART:
- UNICODE_LETTER_FRAGMENT
- | UNICODE_ESCAPE_FRAGMENT
- | '$'
- | UNICODE_COMBINING_MARK_FRAGMENT
- | UNICODE_DIGIT_FRAGMENT
- | UNICODE_CONNECTOR_PUNCTUATION_FRAGMENT
- | ZWNJ
- | ZWJ;
-
-terminal DOT_DOT:
- '..'
-;</programlisting>
-</para>
-</formalpara>
-</section>
-<section xml:id="_n4js-language-grammar">
-<title>N4JS Language Grammar</title>
-<programlisting language="xtext" linenumbering="unnumbered">Script: annotations+=ScriptAnnotation*
- scriptElements+=ScriptElement*;
-
-ScriptElement:
- AnnotatedScriptElement
- | N4ClassDeclaration<Yield=false>
- | N4InterfaceDeclaration<Yield=false>
- | N4EnumDeclaration<Yield=false>
- | ImportDeclaration
- | ExportDeclaration
- | RootStatement<Yield=false>
-;
-
-AnnotatedScriptElement:
- AnnotationList (
- {ExportDeclaration.annotationList=current} ExportDeclarationImpl
- | {ImportDeclaration.annotationList=current} ImportDeclarationImpl
- | {FunctionDeclaration.annotationList=current}
- =>((declaredModifiers+=N4Modifier)* AsyncNoTrailingLineBreak
- ->FunctionImpl<Yield=false,YieldIfGenerator=false,Expression=false>)
- | (
- (
- {N4ClassDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)*
- 'class' typingStrategy=TypingStrategyDefSiteOperator?
- name=BindingIdentifier<Yield=false>
- TypeVariables?
- ClassExtendsClause<Yield=false>?
- | {N4InterfaceDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)*
- 'interface' typingStrategy=TypingStrategyDefSiteOperator? name=BindingIdentifier<Yield=false>
- TypeVariables?
- InterfaceImplementsList?
- )
- Members<Yield=false>
- )
- | {N4EnumDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)*
- 'enum' name=BindingIdentifier<Yield=false>
- '{'
- literals+=N4EnumLiteral (',' literals+= N4EnumLiteral)*
- '}'
- )
-;
-
-fragment TypeVariables*:
- '<' typeVars+=TypeVariable (',' typeVars+=TypeVariable)* '>'
-;
-
-ExportDeclaration:
- ExportDeclarationImpl
-;
-
-fragment ExportDeclarationImpl*:
- 'export' (
- wildcardExport?='*' ExportFromClause Semi
- | ExportClause ->ExportFromClause? Semi
- | exportedElement=ExportableElement
- | defaultExport?='default' (->exportedElement=ExportableElement | defaultExportedExpression=AssignmentExpression<In=true,Yield=false> Semi)
- )
-;
-
-fragment ExportFromClause*:
- 'from' reexportedFrom=[types::TModule|ModuleSpecifier]
-;
-
-fragment ExportClause*:
- '{'
- (namedExports+=ExportSpecifier (',' namedExports+=ExportSpecifier)* ','?)?
- '}'
-;
-
-ExportSpecifier:
- element=IdentifierRef<Yield=false> ('as' alias=IdentifierName)?
-;
-
-ExportableElement:
- AnnotatedExportableElement<Yield=false>
- | N4ClassDeclaration<Yield=false>
- | N4InterfaceDeclaration<Yield=false>
- | N4EnumDeclaration<Yield=false>
- | ExportedFunctionDeclaration<Yield=false>
- | ExportedVariableStatement
-;
-
-AnnotatedExportableElement <Yield>:
- AnnotationList (
- {FunctionDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)* AsyncNoTrailingLineBreak
- FunctionImpl<Yield, Yield, Expression=false>
- | {ExportedVariableStatement.annotationList=current}
- (declaredModifiers+=N4Modifier)*
- varStmtKeyword=VariableStatementKeyword
- varDeclsOrBindings+=ExportedVariableDeclarationOrBinding<Yield> ( ',' varDeclsOrBindings+=ExportedVariableDeclarationOrBinding<Yield> )* Semi
- | (
- (
- {N4ClassDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)*
- 'class' typingStrategy=TypingStrategyDefSiteOperator?
- name=BindingIdentifier<Yield>
- TypeVariables?
- ClassExtendsClause<Yield>?
- | {N4InterfaceDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)*
- ('interface') typingStrategy=TypingStrategyDefSiteOperator? name=BindingIdentifier<Yield>
- TypeVariables?
- InterfaceImplementsList?
- )
- Members<Yield>
- )
- | {N4EnumDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)*
- 'enum' name=BindingIdentifier<Yield>
- '{'
- literals+=N4EnumLiteral (',' literals+= N4EnumLiteral)*
- '}'
- )
-;
-
-ImportDeclaration:
- ImportDeclarationImpl
-;
-
-fragment ImportDeclarationImpl*:
- 'import' (
- ImportClause importFrom?='from'
- )? module=[types::TModule|ModuleSpecifier] Semi
-;
-
-fragment ImportClause*:
- importSpecifiers+=DefaultImportSpecifier (',' ImportSpecifiersExceptDefault)?
- | ImportSpecifiersExceptDefault
-;
-
-fragment ImportSpecifiersExceptDefault*:
- importSpecifiers+=NamespaceImportSpecifier
- | '{' (importSpecifiers+=NamedImportSpecifier (',' importSpecifiers+=NamedImportSpecifier)* ','?)? '}'
-;
-
-NamedImportSpecifier:
- importedElement=[types::TExportableElement|BindingIdentifier<Yield=false>]
- | importedElement=[types::TExportableElement|IdentifierName] 'as' alias=BindingIdentifier<Yield=false>
-;
-
-DefaultImportSpecifier:
- importedElement=[types::TExportableElement|BindingIdentifier<Yield=false>]
-;
-
-NamespaceImportSpecifier: '*' 'as' alias=BindingIdentifier<false> (declaredDynamic?='+')?;
-
-ModuleSpecifier: STRING;
-
-FunctionDeclaration <Yield>:
- => ((declaredModifiers+=N4Modifier)* AsyncNoTrailingLineBreak
- -> FunctionImpl <Yield,Yield,Expression=false>
- ) => Semi?
-;
-
-fragment AsyncNoTrailingLineBreak *: (declaredAsync?='async' NoLineTerminator)?;
-
-fragment FunctionImpl<Yield, YieldIfGenerator, Expression>*:
- 'function'
- (
- generator?='*' FunctionHeader<YieldIfGenerator,Generator=true> FunctionBody<Yield=true,Expression>
- | FunctionHeader<Yield,Generator=false> FunctionBody<Yield=false,Expression>
- )
-;
-
-fragment FunctionHeader<Yield, Generator>*:
- TypeVariables?
- name=BindingIdentifier<Yield>?
- StrictFormalParameters<Yield=Generator>
- (-> ':' returnTypeRef=TypeRef)?
-;
-
-fragment FunctionBody <Yield, Expression>*:
- <Expression> body=Block<Yield>
- | <!Expression> body=Block<Yield>?
-;
-
-ExportedFunctionDeclaration<Yield>:
- FunctionDeclaration<Yield>
-;
-
-FunctionTypeExpression:
- {types::FunctionTypeExpression}
- '{'
- ('@' 'This' '(' declaredThisType=TypeRefFunctionTypeExpression ')')?
- 'function'
- ('<' ownedTypeVars+=TypeVariable (',' ownedTypeVars+=TypeVariable)* '>')?
- '('
- (fpars+=TAnonymousFormalParameter (',' fpars+=TAnonymousFormalParameter)*)?
- ')'
- (':' returnTypeRef=TypeRef)?
- '}';
-
-AnnotatedFunctionDeclaration <Yield, Default>:
- annotationList=AnnotationList
- (declaredModifiers+=N4Modifier)* AsyncNoTrailingLineBreak
- FunctionImpl<Yield,Yield,Expression=false>
-;
-
-
-FunctionExpression:
- (FunctionImpl<Yield=false,YieldIfGenerator=true,Expression=true>
- )
-;
-
-AsyncFunctionExpression:
- =>(declaredAsync?='async' NoLineTerminator 'function')
- FunctionHeader<Yield=false,Generator=false> FunctionBody<Yield=false,Expression=true>
-;
-
-ArrowExpression <In, Yield>:
- => (
- (
- '(' (fpars+=FormalParameter<Yield>
- (',' fpars+=FormalParameter<Yield>)*)?
- ')' (':' returnTypeRef=TypeRef)?
- | =>(declaredAsync?='async' NoLineTerminator '(')
- (fpars+=FormalParameter<Yield> (',' fpars+=FormalParameter<Yield>)*)?
- ')' (':' returnTypeRef=TypeRef)?
- | fpars+=BindingIdentifierAsFormalParameter<Yield>
- )
- '=>'
- )
- (-> hasBracesAroundBody?='{' body=BlockMinusBraces<Yield> '}'
- | body=ExpressionDisguisedAsBlock<In>)
-;
-
-fragment StrictFormalParameters <Yield>*:
- '(' (fpars+=FormalParameter<Yield> (',' fpars+=FormalParameter<Yield>)*)? ')'
-;
-
-BindingIdentifierAsFormalParameter <Yield>: name=BindingIdentifier<Yield>;
-
-BlockMinusBraces <Yield>: statements+=Statement<Yield>*;
-
-ExpressionDisguisedAsBlock <In>:
- statements+=AssignmentExpressionStatement<In>
-;
-
-AssignmentExpressionStatement <In>: expression=AssignmentExpression<In,Yield=false>;
-
-AnnotatedExpression <Yield>:
- ExpressionAnnotationList (
- {N4ClassExpression.annotationList=current}
- 'class' name=BindingIdentifier<Yield>?
- ClassExtendsClause<Yield>?
- Members<Yield>
- | {FunctionExpression.annotationList=current} AsyncNoTrailingLineBreak
- FunctionImpl<Yield=false,YieldIfGenerator=true,Expression=true>
- )
-;
-
-TypeVariable:
- name=IdentifierOrThis
- ( 'extends' declaredUpperBounds+=ParameterizedTypeRefNominal
- ('&' declaredUpperBounds+=ParameterizedTypeRefNominal)*
- )?
-;
-
-FormalParameter <Yield>:
- BindingElementFragment<Yield>
-;
-
-fragment BindingElementFragment <Yield>*:
- (=> bindingPattern=BindingPattern<Yield>
- | annotations+=Annotation*
- (
- variadic?='...'? name=BindingIdentifier<Yield> ColonSepTypeRef?
- )
- )
- ('=' initializer=AssignmentExpression<In=true, Yield>)?
-;
-
-fragment ColonSepTypeRef*:
- ':' declaredTypeRef=TypeRef
-;
-
-Block <Yield>: => ('{') statements+=Statement<Yield>* '}';
-RootStatement <Yield>:
- Block<Yield>
- | FunctionDeclaration<Yield>
- | VariableStatement<In=true,Yield>
- | EmptyStatement
- | LabelledStatement<Yield>
- | ExpressionStatement<Yield>
- | IfStatement<Yield>
- | IterationStatement<Yield>
- | ContinueStatement<Yield>
- | BreakStatement<Yield>
- | ReturnStatement<Yield>
- | WithStatement<Yield>
- | SwitchStatement<Yield>
- | ThrowStatement<Yield>
- | TryStatement<Yield>
- | DebuggerStatement
-;
-
-Statement <Yield>:
- AnnotatedFunctionDeclaration<Yield,Default=false>
- | RootStatement<Yield>
-;
-
-enum VariableStatementKeyword:
- var='var' | const='const' | let='let'
-;
-
-VariableStatement <In, Yield>:
- =>(varStmtKeyword=VariableStatementKeyword
- )
- varDeclsOrBindings+=VariableDeclarationOrBinding<In,Yield,false>
- (',' varDeclsOrBindings+=VariableDeclarationOrBinding<In,Yield,false>)* Semi
-;
-
-ExportedVariableStatement:
- (declaredModifiers+=N4Modifier)*
- varStmtKeyword=VariableStatementKeyword
- varDeclsOrBindings+=ExportedVariableDeclarationOrBinding<Yield=false>
- (',' varDeclsOrBindings+=ExportedVariableDeclarationOrBinding<Yield=false>)* Semi
-;
-
-VariableDeclarationOrBinding <In, Yield, OptionalInit>:
- VariableBinding<In,Yield,OptionalInit>
- | VariableDeclaration<In,Yield,true>
-;
-
-VariableBinding <In, Yield, OptionalInit>:
- => pattern=BindingPattern<Yield> (
- <OptionalInit> ('=' expression=AssignmentExpression<In,Yield>)?
- | <!OptionalInit> '=' expression=AssignmentExpression<In,Yield>
- )
-;
-
-VariableDeclaration <In, Yield, AllowType>:
- VariableDeclarationImpl<In,Yield,AllowType>;
-
-fragment VariableDeclarationImpl <In, Yield, AllowType>*:
- annotations+=Annotation*
- (
- <AllowType> =>(
- name=BindingIdentifier<Yield> ColonSepTypeRef?
- ) ('=' expression=AssignmentExpression<In,Yield>)?
- | <!AllowType> =>(
- name=BindingIdentifier<Yield>
- ) ('=' expression=AssignmentExpression<In,Yield>)?
- )
-;
-
-ExportedVariableDeclarationOrBinding <Yield>:
- ExportedVariableBinding<Yield>
- | ExportedVariableDeclaration<Yield>
-;
-
-ExportedVariableBinding <Yield>:
- => pattern=BindingPattern<Yield> '=' expression=AssignmentExpression<In=true,Yield>
-;
-
-ExportedVariableDeclaration <Yield>:
- VariableDeclarationImpl<In=true,Yield,AllowType=true>
-;
-EmptyStatement: ';';
-ExpressionStatement <Yield>: expression=Expression<In=true,Yield> Semi;
-
-IfStatement <Yield>: 'if' '(' expression=Expression<In=true,Yield> ')'
- ifStmt=Statement<Yield> (=> 'else' elseStmt=Statement<Yield>)?;
-
-IterationStatement <Yield>:
- DoStatement<Yield>
- | WhileStatement<Yield>
- | ForStatement<Yield>
-;
-
-DoStatement <Yield>: 'do' statement=Statement<Yield> 'while'
- '(' expression=Expression<In=true,Yield> ')' => Semi?;
-WhileStatement <Yield>: 'while' '(' expression=Expression<In=true,Yield> ')'
- statement=Statement<Yield>;
-
-ForStatement <Yield>:
- 'for' '('
- (
- =>(initExpr=LetIdentifierRef forIn?='in' expression=Expression<In=true,Yield> ')')
- | ( ->varStmtKeyword=VariableStatementKeyword
- (
- =>(varDeclsOrBindings+=BindingIdentifierAsVariableDeclaration<In=false,Yield>
- (forIn?='in' | forOf?='of') ->expression=AssignmentExpression<In=true,Yield>?)
- | varDeclsOrBindings+=VariableDeclarationOrBinding<In=false,Yield,OptionalInit=true>
- (
- (',' varDeclsOrBindings+=VariableDeclarationOrBinding<In=false,Yield,false>)* ';'
- expression=Expression<In=true,Yield>? ';' updateExpr=Expression<In=true,Yield>?
- | forIn?='in' expression=Expression<In=true,Yield>?
- | forOf?='of' expression=AssignmentExpression<In=true,Yield>?
- )
- )
- | initExpr=Expression<In=false,Yield>
- (
- ';' expression=Expression<In=true,Yield>? ';' updateExpr=Expression<In=true,Yield>?
- | forIn?='in' expression=Expression<In=true,Yield>?
- | forOf?='of' expression=AssignmentExpression<In=true,Yield>?
- )
- | ';' expression=Expression<In=true,Yield>? ';' updateExpr=Expression<In=true,Yield>?
- )
- ')'
- ) statement=Statement<Yield>
-;
-
-LetIdentifierRef:
- id=[types::IdentifiableElement|LetAsIdentifier]
-;
-
-LetAsIdentifier: 'let';
-
-BindingIdentifierAsVariableDeclaration <In, Yield>:
- name=BindingIdentifier<Yield>
-;
-
-ContinueStatement <Yield>: 'continue' (label=[LabelledStatement|BindingIdentifier<Yield>])? Semi;
-
-BreakStatement <Yield>: 'break' (label=[LabelledStatement|BindingIdentifier<Yield>])? Semi;
-
-ReturnStatement <Yield>: 'return' (expression=Expression<In=true,Yield>)? Semi;
-
-WithStatement <Yield>: 'with' '(' expression=Expression<In=true,Yield> ')' statement=Statement<Yield>;
-
-SwitchStatement <Yield>:
- 'switch' '(' expression=Expression<In=true,Yield> ')' '{'
- (cases+=CaseClause<Yield>)*
- ((cases+=DefaultClause<Yield>)
- (cases+=CaseClause<Yield>)*)? '}'
-;
-
-CaseClause <Yield>: 'case' expression=Expression<In=true,Yield> ':' (statements+=Statement<Yield>)*;
-
-DefaultClause <Yield>: 'default' ':' (statements+=Statement<Yield>)*;
-
-LabelledStatement <Yield>: => (name=BindingIdentifier<Yield> ':') statement=Statement<Yield>;
-
-ThrowStatement <Yield>:
- 'throw' expression=Expression<In=true,Yield> Semi;
-
-TryStatement <Yield>:
- 'try' block=Block<Yield>
- ((catch=CatchBlock<Yield> finally=FinallyBlock<Yield>?) | finally=FinallyBlock<Yield>)
-;
-
-CatchBlock <Yield>: 'catch' '(' catchVariable=CatchVariable<Yield> ')' block=Block<Yield>;
-
-CatchVariable <Yield>:
- =>bindingPattern=BindingPattern<Yield>
- | =>(name=BindingIdentifier<Yield> -> ColonSepTypeRef)
- | name=BindingIdentifier<Yield>
-;
-
-FinallyBlock <Yield>: 'finally' block=Block<Yield>;
-
-DebuggerStatement:
- 'debugger' Semi;
-
-PrimaryExpression <Yield>:
- ThisLiteral
- | SuperLiteral
- | IdentifierRef<Yield>
- | ParameterizedCallExpression<Yield>
- | Literal
- | ArrayLiteral<Yield>
- | ObjectLiteral<Yield>
- | ParenExpression<Yield>
- | AnnotatedExpression<Yield>
- | FunctionExpression
- | AsyncFunctionExpression
- | N4ClassExpression<Yield>
- | TemplateLiteral<Yield>
-;
-
-ParenExpression <Yield>: '(' expression=Expression<In=true,Yield> ')';
-
-IdentifierRef <Yield>:
- id=[types::IdentifiableElement|BindingIdentifier<Yield>]
-;
-
-SuperLiteral: 'super';
-
-ThisLiteral: 'this';
-
-ArrayLiteral <Yield>:
- '['
- elements+=ArrayPadding* (
- elements+=ArrayElement<Yield>
- (',' elements+=ArrayPadding* elements+=ArrayElement<Yield>)*
- (trailingComma?=',' elements+=ArrayPadding*)?
- )?
- ']'
-;
-
-ArrayPadding: ',';
-
-ArrayElement <Yield>: spread?='...'? expression=AssignmentExpression<In=true,Yield>;
-
-ObjectLiteral <Yield>: '{'
- ( propertyAssignments+=PropertyAssignment<Yield>
- (',' propertyAssignments+=PropertyAssignment<Yield>)* ','?
- )?
- '}'
-;
-
-PropertyAssignment <Yield>:
- AnnotatedPropertyAssignment<Yield>
- | PropertyNameValuePair<Yield>
- | PropertyGetterDeclaration<Yield>
- | PropertySetterDeclaration<Yield>
- | PropertyMethodDeclaration<Yield>
- | PropertyNameValuePairSingleName<Yield>
-;
-
-AnnotatedPropertyAssignment <Yield>:
- PropertyAssignmentAnnotationList (
- =>( {PropertyNameValuePair.annotationList=current} declaredTypeRef=TypeRef?
- LiteralOrComputedPropertyName<Yield> ':'
- ) expression=AssignmentExpression<In=true,Yield>
- | =>({PropertyGetterDeclaration.annotationList=current}
- GetterHeader<Yield>
- ) body=Block<Yield=false>
- | =>({PropertySetterDeclaration.annotationList=current}
- 'set' ->LiteralOrComputedPropertyName <Yield>
- ) '(' fpar=FormalParameter<Yield> ')' body=Block<Yield=false>
- | =>({PropertyMethodDeclaration.annotationList=current}
- TypeVariables? returnTypeRef=TypeRef?
- (generator?='*' LiteralOrComputedPropertyName<Yield> ->MethodParamsAndBody <Generator=true>
- | LiteralOrComputedPropertyName<Yield> -> MethodParamsAndBody <Generator=false>
- )
- ) ';'?
- | {PropertyNameValuePairSingleName.annotationList=current}
- declaredTypeRef=TypeRef? identifierRef=IdentifierRef<Yield>
- ( '=' expression=AssignmentExpression<In=true,Yield>)?)
-;
-
-PropertyMethodDeclaration <Yield>:
- => (TypeVariables? returnTypeRef=TypeRef?
- (
- generator?='*' LiteralOrComputedPropertyName<Yield>
- ->MethodParamsAndBody<Generator=true>
- | LiteralOrComputedPropertyName<Yield> ->MethodParamsAndBody <Generator=false>
- )
- )
- ';'?
-;
-
-PropertyNameValuePair <Yield>:
- => (
- declaredTypeRef=TypeRef? LiteralOrComputedPropertyName<Yield> ':'
- )
- expression=AssignmentExpression<In=true,Yield>
-;
-
-PropertyNameValuePairSingleName <Yield>:
- declaredTypeRef=TypeRef?
- identifierRef=IdentifierRef<Yield>
- ('=' expression=AssignmentExpression<In=true,Yield>)?
-;
-
-PropertyGetterDeclaration <Yield>:
- =>(
- GetterHeader<Yield>
- )
- body=Block<Yield=false>
-;
-
-PropertySetterDeclaration <Yield>:
- =>(
- 'set'
- ->LiteralOrComputedPropertyName <Yield>
- )
- '(' fpar=FormalParameter<Yield> ')' body=Block<Yield=false>
-;
-
-ParameterizedCallExpression <Yield>:
- TypeArguments
- target=IdentifierRef<Yield>
- ArgumentsWithParentheses<Yield>
-;
-
-LeftHandSideExpression <Yield>:
- MemberExpression<Yield> (
- {ParameterizedCallExpression.target=current} ArgumentsWithParentheses<Yield>
- (
- {ParameterizedCallExpression.target=current} ArgumentsWithParentheses<Yield>
- | {IndexedAccessExpression.target=current} IndexedAccessExpressionTail<Yield>
- | {ParameterizedPropertyAccessExpression.target=current}
- ParameterizedPropertyAccessExpressionTail<Yield>
- | ->({TaggedTemplateString.target=current} template=TemplateLiteral<Yield>)
- )*
- )?
-;
-
-fragment Arguments <Yield>*:
- arguments+=AssignmentExpression<In=true,Yield>
- (',' arguments+=AssignmentExpression<In=true,Yield>)*
- (',' spread?='...' arguments+=AssignmentExpression<In=true,Yield>)?
- | spread?='...' arguments+=AssignmentExpression<In=true,Yield>
-;
-
-fragment TypeArguments*:
- '<' typeArgs+=TypeRef (',' typeArgs+=TypeRef)* '>'
-;
-
-fragment ArgumentsWithParentheses <Yield>*:
- '(' Arguments<Yield>? ')'
-;
-
-MemberExpression <Yield>:
- =>('new' '.') 'target'
- | => ('new') callee=MemberExpression<Yield> (-> TypeArguments)?
- (=> withArgs?='(' Arguments<Yield>? ')'
- (
- {IndexedAccessExpression.target=current} IndexedAccessExpressionTail<Yield>
- | {ParameterizedPropertyAccessExpression.target=current}
- ParameterizedPropertyAccessExpressionTail<Yield>
- | {TaggedTemplateString.target=current} template=TemplateLiteral<Yield>
- )*
- )?
- | PrimaryExpression<Yield> (
- {IndexedAccessExpression.target=current} IndexedAccessExpressionTail<Yield>
- | {ParameterizedPropertyAccessExpression.target=current}
- ParameterizedPropertyAccessExpressionTail<Yield>
- | {TaggedTemplateString.target=current} template=TemplateLiteral<Yield>
- )*
-;
-
-fragment IndexedAccessExpressionTail <Yield>*:
- '[' index=Expression<In=true,Yield> ']'
-;
-
-fragment ParameterizedPropertyAccessExpressionTail <Yield>*:
- '.' TypeArguments? property=[types::IdentifiableElement|IdentifierName]
-;
-
-PostfixExpression <Yield>:
- LeftHandSideExpression<Yield> (
- =>({PostfixExpression.expression=current} op=PostfixOperator
- )
- )?
-;
-
-enum PostfixOperator: inc='++' | dec='--';
-
-CastExpression <Yield>: PostfixExpression<Yield>
- (=>({CastExpression.expression=current} 'as') targetTypeRef=TypeRefForCast)?;
-
-UnaryExpression <Yield>:
- CastExpression<Yield>
- | (op=UnaryOperator expression=UnaryExpression<Yield>);
-
-enum UnaryOperator: delete | void | typeof | inc='++' | dec='--' | pos='+' | neg='-' | inv='~' | not='!';
-
-MultiplicativeExpression <Yield>: UnaryExpression<Yield>
- (=>({MultiplicativeExpression.lhs=current} op=MultiplicativeOperator)
- rhs=UnaryExpression<Yield>)*;
-
-enum MultiplicativeOperator: times='*' | div='/' | mod='%';
-
-AdditiveExpression <Yield>: MultiplicativeExpression<Yield>
- (=>({AdditiveExpression.lhs=current} op=AdditiveOperator)
- rhs=MultiplicativeExpression<Yield>)*;
-
-enum AdditiveOperator: add='+' | sub='-';
-
-ShiftExpression <Yield>: AdditiveExpression<Yield>
- (=>({ShiftExpression.lhs=current} op=ShiftOperator rhs=AdditiveExpression<Yield>))*
-;
-
-ShiftOperator:
- '>' '>' '>'?
- | '<<'
-;
-
-RelationalExpression <In, Yield>: ShiftExpression<Yield>
- =>({RelationalExpression.lhs=current} op=RelationalOperator<In>
- ->rhs=ShiftExpression<Yield>)*;
-
-RelationalOperator <In>:
- '<' | '>' | '<=' | '>=' | 'instanceof' | <In> 'in';
-
-EqualityExpression <In, Yield>: RelationalExpression<In,Yield>
- (=>({EqualityExpression.lhs=current} op=EqualityOperator) rhs=RelationalExpression<In,Yield>)*;
-
-enum EqualityOperator: same='===' | nsame='!==' | eq='==' | neq='!=';
-
-BitwiseANDExpression <In, Yield>: EqualityExpression<In,Yield>
- (=>({BinaryBitwiseExpression.lhs=current} op=BitwiseANDOperator) rhs=EqualityExpression<In,Yield>)*;
-
-BitwiseANDOperator: '&';
-
-BitwiseXORExpression <In, Yield>: BitwiseANDExpression<In,Yield>
- (=>({BinaryBitwiseExpression.lhs=current} op=BitwiseXOROperator) rhs=BitwiseANDExpression<In,Yield>)*;
-
-BitwiseXOROperator: '^';
-
-BitwiseORExpression <In, Yield>: BitwiseXORExpression<In,Yield>
- (=>({BinaryBitwiseExpression.lhs=current} op=BitwiseOROperator) rhs=BitwiseXORExpression<In,Yield>)*;
-
-BitwiseOROperator: '|';
-
-LogicalANDExpression <In, Yield>: BitwiseORExpression<In,Yield>
- (=> ({BinaryLogicalExpression.lhs=current} op=LogicalANDOperator) rhs=BitwiseORExpression<In,Yield>)*;
-
-LogicalANDOperator: '&&';
-
-LogicalORExpression <In, Yield>: LogicalANDExpression<In,Yield>
- (=>({BinaryLogicalExpression.lhs=current} op=LogicalOROperator) rhs=LogicalANDExpression<In,Yield>)*;
-
-LogicalOROperator: '||';
-
-ConditionalExpression <In, Yield>: LogicalORExpression<In,Yield>
- (=> ({ConditionalExpression.expression=current} '?') trueExpression=AssignmentExpression<In=true,Yield>
- ':' falseExpression=AssignmentExpression<In,Yield>)?;
-
-AssignmentExpression <In, Yield>:
- AwaitExpression<In,Yield>
- | PromisifyExpression<In,Yield>
- | ArrowExpression<In,Yield>
- | <Yield> YieldExpression<In>
- | ConditionalExpression<In,Yield>
- (=> ({AssignmentExpression.lhs=current} op=AssignmentOperator)
- rhs=AssignmentExpression<In,Yield>)?
-;
-
-YieldExpression <In>:
- 'yield' => many?='*'? -> expression=AssignmentExpression<In,Yield=true>?
-;
-
-AssignmentOperator:
- '=' | '*=' | '/=' | '%=' | '+=' | '-='
- | '<<='
- | '>' '>'? '>='
- | '&=' | '^=' | '|='
-;
-
-AwaitExpression <In, Yield>:
- =>('await') expression=AssignmentExpression<In,Yield>;
-
-PromisifyExpression <In, Yield>:
- => ('@' 'Promisify') expression=AssignmentExpression<In,Yield>;
-
-Expression <In, Yield>:
- AssignmentExpression<In,Yield> ({CommaExpression.exprs+=current}
- ',' exprs+=AssignmentExpression<In,Yield>
- (',' exprs+=AssignmentExpression<In,Yield>)*)?
-;
-
-TemplateLiteral <Yield>:
- (
- segments+=NoSubstitutionTemplate
- | segments+=TemplateHead segments+=Expression<In=true,Yield>? TemplateExpressionEnd
- (
- segments+=TemplateMiddle segments+=Expression<In=true,Yield>?
- TemplateExpressionEnd
- )*
- segments+=TemplateTail
- )
-;
-
-TemplateExpressionEnd:
- '}'
-;
-
-NoSubstitutionTemplate:
- rawValue=NO_SUBSTITUTION_TEMPLATE_LITERAL
-;
-
-TemplateHead:
- rawValue=TEMPLATE_HEAD
-;
-
-TemplateTail:
- rawValue=TemplateTailLiteral;
-
-TemplateMiddle:
- rawValue=TemplateMiddleLiteral;
-
-Literal:
- NumericLiteral | BooleanLiteral | StringLiteral
- | NullLiteral | RegularExpressionLiteral;
-NullLiteral: 'null';
-BooleanLiteral: (true?='true' | 'false');
-StringLiteral: value=STRING;
-NumericLiteral:
- DoubleLiteral | IntLiteral | BinaryIntLiteral | OctalIntLiteral
- | LegacyOctalIntLiteral | HexIntLiteral | ScientificIntLiteral;
-DoubleLiteral: value=DOUBLE;
-IntLiteral: value=INT;
-OctalIntLiteral: value=OCTAL_INT;
-LegacyOctalIntLiteral: value=LEGACY_OCTAL_INT;
-HexIntLiteral: value=HEX_INT;
-BinaryIntLiteral: value=BINARY_INT;
-ScientificIntLiteral: value=SCIENTIFIC_INT;
-RegularExpressionLiteral: value=REGEX_LITERAL;
-
-NumericLiteralAsString:
- DOUBLE | INT | OCTAL_INT | HEX_INT | SCIENTIFIC_INT
-;
-
-IdentifierOrThis:
- IDENTIFIER
- | 'This'
- | 'Promisify'
- | 'target';
-
-AnnotationName:
- IDENTIFIER
- | 'This'
- | 'target';
-
-BindingIdentifier <Yield>:
- IDENTIFIER
- | <!Yield> 'yield'
- | N4Keyword
-;
-
-IdentifierName:
- IDENTIFIER | ReservedWord | N4Keyword
-;
-
-ReservedWord:
- 'break' | 'case' | 'catch' | 'class' | 'const' | 'continue' | 'debugger' | 'default' | 'delete'
- | 'do' | 'else' | 'export' | 'extends' | 'finally' | 'for' | 'function' | 'if' | 'import'
- | 'in' | 'instanceof' | 'new' | 'return' | 'super' | 'switch' | 'this' | 'throw' | 'try'
- | 'typeof' | 'var' | 'void' | 'while' | 'with' | 'yield'
- | 'null'
- | 'true' | 'false'
- | 'enum';
-
-N4Keyword:
- 'get' | 'set'
- | 'let'
- | 'project'
- | 'external' | 'abstract' | 'static'
- | 'as' | 'from' | 'constructor' | 'of' | 'target'
- | 'type' | 'union' | 'intersection'
- | 'This' | 'Await' | 'Promisify'
- | 'await'
- | 'async'
- | 'implements' | 'interface'
- | 'private' | 'protected' | 'public'
-;
-
-SymbolLiteralComputedName <Yield>:
- BindingIdentifier<Yield> ('.' IdentifierName)?
-;
-
-terminal DOUBLE:
- '.' DECIMAL_DIGIT_FRAGMENT+ EXPONENT_PART?
- | DECIMAL_INTEGER_LITERAL_FRAGMENT '.' DECIMAL_DIGIT_FRAGMENT* EXPONENT_PART?
-;
-
-terminal HEX_INT: '0' ('x' | 'X') INT_SUFFIX;
-
-terminal BINARY_INT: '0' ('b' | 'B') INT_SUFFIX;
-
-terminal OCTAL_INT: '0' ('o' | 'O') INT_SUFFIX;
-
-terminal LEGACY_OCTAL_INT: '0' DECIMAL_DIGIT_FRAGMENT INT_SUFFIX;
-
-terminal fragment INT_SUFFIX: IDENTIFIER_PART*;
-
-terminal SCIENTIFIC_INT:
- DECIMAL_INTEGER_LITERAL_FRAGMENT EXPONENT_PART
-;
-
-terminal fragment EXPONENT_PART:
- ('e' | 'E') SIGNED_INT
- | IDENTIFIER
-;
-
-terminal fragment SIGNED_INT:
- ('+' | '-') DECIMAL_DIGIT_FRAGMENT+ IDENTIFIER?
-;
-
-terminal STRING:
- '"' DOUBLE_STRING_CHAR* '"'?
- | "'" SINGLE_STRING_CHAR* "'"?
-;
-
-terminal fragment DOUBLE_STRING_CHAR:
- !(LINE_TERMINATOR_FRAGMENT | '"' | '\\')
- | '\\' (LINE_TERMINATOR_SEQUENCE_FRAGMENT | !LINE_TERMINATOR_FRAGMENT)?
-;
-
-terminal fragment SINGLE_STRING_CHAR:
- !(LINE_TERMINATOR_FRAGMENT | "'" | '\\')
- | '\\' (LINE_TERMINATOR_SEQUENCE_FRAGMENT | !LINE_TERMINATOR_FRAGMENT)?
-;
-
-terminal fragment BACKSLASH_SEQUENCE:
- '\\' !(LINE_TERMINATOR_FRAGMENT)?
-;
-
-terminal fragment REGEX_CHAR:
- !(LINE_TERMINATOR_FRAGMENT | '\\' | '/' | '[')
- | BACKSLASH_SEQUENCE
- | '[' REGEX_CHAR_OR_BRACKET* ']'?
-;
-
-terminal fragment REGEX_CHAR_OR_BRACKET:
- !(LINE_TERMINATOR_FRAGMENT | '\\' | ']')
- | BACKSLASH_SEQUENCE
-;
-
-REGEX_LITERAL:
- ('/' | '/=') REGEX_TAIL?
-;
-
-terminal fragment ACTUAL_REGEX_TAIL:
- REGEX_CHAR+ ('/' IDENTIFIER_PART*)?
- | '/' IDENTIFIER_PART*
-;
-
-terminal fragment REGEX_START:
- ('/' | '/=')
-;
-
-terminal REGEX_TAIL: // post processed
- '//1'
-;
-terminal TEMPLATE_HEAD:
- "`" TEMPLATE_LITERAL_CHAR* '$'+ '{'
-;
-
-terminal NO_SUBSTITUTION_TEMPLATE_LITERAL:
- '`' TEMPLATE_LITERAL_CHAR* '$'* "`"?
-;
-
-terminal fragment ACTUAL_TEMPLATE_END:
- TEMPLATE_LITERAL_CHAR* ('$'+ ('{' | '`'?) | '`'?)
-;
-
-terminal fragment TEMPLATE_LITERAL_CHAR:
- !(LINE_TERMINATOR_FRAGMENT | '`' | '\\' | '$')
- | '$'+ !('{' | '`' | '$')
- | LINE_TERMINATOR_SEQUENCE_FRAGMENT
- | '\\' (LINE_TERMINATOR_SEQUENCE_FRAGMENT | !LINE_TERMINATOR_FRAGMENT)?
-;
-
-TemplateTailLiteral:
- TEMPLATE_END?
-;
-
-TemplateMiddleLiteral:
- TEMPLATE_MIDDLE
-;
-
-terminal TEMPLATE_MIDDLE:
- '//2' // will never be lexed
-;
-
-terminal TEMPLATE_END:
- '//3' // will never be lexed
-;
-
-terminal fragment TEMPLATE_CONTINUATION:
- '//4' // actually '}'
-;
-
-Semi: ';'; // automatic semicolon instertion, post-processed
-
-fragment NoLineTerminator*: NO_LINE_TERMINATOR?;
-
-terminal NO_LINE_TERMINATOR:
- '//5' // post-processed, will never be lexed
-;
-Annotation:'@' AnnotationNoAtSign;
-ScriptAnnotation: '@@' AnnotationNoAtSign;
-
-AnnotationNoAtSign:
- name=AnnotationName (=> '(' (args+=AnnotationArgument (',' args+=AnnotationArgument)*)? ')')?;
-
-AnnotationArgument:
- LiteralAnnotationArgument | TypeRefAnnotationArgument
-;
-
-LiteralAnnotationArgument:
- literal=Literal
-;
-
-TypeRefAnnotationArgument:
- typeRef=TypeRef
-;
-
-AnnotationList:
- =>('@' -> annotations+=AnnotationNoAtSign) annotations+=Annotation*
-;
-
-ExpressionAnnotationList:
- annotations+=Annotation+
-;
-
-PropertyAssignmentAnnotationList:
- annotations+=Annotation+
-;
-
-N4MemberAnnotationList:
- {N4MemberAnnotationList} annotations+=Annotation+
-;
-
-TypeReferenceName:
- 'void' | 'This' | 'await' | 'Promisify' | 'target' | QualifiedTypeReferenceName
-;
-
-QualifiedTypeReferenceName:
- IDENTIFIER ('.' IDENTIFIER)?
-;
-N4ClassDeclaration <Yield>:
- =>(
- {N4ClassDeclaration}
- (declaredModifiers+=N4Modifier)*
- 'class' typingStrategy=TypingStrategyDefSiteOperator? name=BindingIdentifier<Yield>?
- )
- TypeVariables?
- ClassExtendsClause<Yield>?
- Members<Yield>
-;
-
-fragment Members <Yield>*:
- '{'
- ownedMembersRaw+=N4MemberDeclaration<Yield>*
- '}'
-;
-
-fragment ClassExtendsClause <Yield>*:
- 'extends' (
- =>superClassRef=ParameterizedTypeRefNominal ('implements' ClassImplementsList)?
- | superClassExpression=LeftHandSideExpression<Yield>
- )
- | 'implements' ClassImplementsList
-;
-
-fragment ClassImplementsList*:
- implementedInterfaceRefs+=ParameterizedTypeRefNominal
- (',' implementedInterfaceRefs+=ParameterizedTypeRefNominal)*
-;
-
-N4ClassExpression <Yield>:
- {N4ClassExpression}
- 'class' name=BindingIdentifier<Yield>?
- ClassExtendsClause<Yield>?
- Members<Yield>;
-N4InterfaceDeclaration <Yield>:
- => (
- {N4InterfaceDeclaration}
- (declaredModifiers+=N4Modifier)*
- 'interface' typingStrategy=TypingStrategyDefSiteOperator? name=BindingIdentifier<Yield>?
- )
- TypeVariables?
- InterfaceImplementsList?
- Members<Yield>
-;
-
-fragment InterfaceImplementsList*:
- 'extends' superInterfaceRefs+=ParameterizedTypeRefNominal
- (',' superInterfaceRefs+=ParameterizedTypeRefNominal)*
-;
-N4EnumDeclaration <Yield>:
- =>(
- {N4EnumDeclaration}
- (declaredModifiers+=N4Modifier)*
- 'enum' name=BindingIdentifier<Yield>?
- )
- '{'
- (literals+=N4EnumLiteral (',' literals+=N4EnumLiteral)*)?
- '}'
-;
-N4EnumLiteral: name=IdentifierOrThis (':' value=STRING)?;
-
-enum N4Modifier: // validator applies further checks
- private | project | protected | public
- | external | abstract | static | const;
-
-N4MemberDeclaration <Yield>:
- AnnotatedN4MemberDeclaration<Yield>
- | N4GetterDeclaration<Yield>
- | N4SetterDeclaration<Yield>
- | N4MethodDeclaration<Yield>
- | N4FieldDeclaration<Yield>
- | N4CallableConstructorDeclaration<Yield>
-;
-
-AnnotatedN4MemberDeclaration <Yield> returns N4MemberDeclaration:
- N4MemberAnnotationList (
- => ({N4GetterDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)* GetterHeader<Yield>) (body=Block<Yield>)? ';'?
- | => ({N4SetterDeclaration.annotationList=current}
- (declaredModifiers+=N4Modifier)* 'set' -> LiteralOrComputedPropertyName <Yield>)
- '(' fpar=FormalParameter<Yield> ')' (body=Block<Yield>)? ';'?
- | => (
- {N4MethodDeclaration.annotationList=current} (declaredModifiers+=N4Modifier)* TypeVariables?
- (
- generator?='*' LiteralOrComputedPropertyName<Yield>
- ->MethodParamsReturnAndBody <Generator=true>
- | AsyncNoTrailingLineBreak LiteralOrComputedPropertyName<Yield>
- ->MethodParamsReturnAndBody <Generator=false>
- )
- )';'?
- | {N4FieldDeclaration.annotationList=current} FieldDeclarationImpl<Yield>
- )
-;
-
-fragment LiteralOrComputedPropertyName <Yield>*:
- name=IdentifierName | name=STRING | name=NumericLiteralAsString
- | '[' (=>((name=SymbolLiteralComputedName<Yield> | name=StringLiteralAsName) ']')
- | computeNameFrom=AssignmentExpression<In=true,Yield> ']')
-;
-
-fragment LiteralPropertyName <Yield>*:
- name=IdentifierName | name=STRING | name=NumericLiteralAsString
- | '[' (name=SymbolLiteralComputedName<Yield> | name=StringLiteralAsName) ']'
-;
-
-StringLiteralAsName:
- STRING
-;
-
-fragment FieldDeclarationImpl <Yield>*:
- (declaredModifiers+=N4Modifier)*
- LiteralPropertyName<Yield> ColonSepTypeRef? ('=' expression=Expression<In=true,Yield>)? ';'
-;
-
-N4FieldDeclaration <Yield>:
- {N4FieldDeclaration}
- FieldDeclarationImpl<Yield>
-;
-
-N4MethodDeclaration <Yield>:
- => ({N4MethodDeclaration} (declaredModifiers+=N4Modifier)* TypeVariables?
- (
- generator?='*' LiteralOrComputedPropertyName<Yield>
- ->MethodParamsReturnAndBody <Generator=true>
- | AsyncNoTrailingLineBreak LiteralOrComputedPropertyName<Yield>
- ->MethodParamsReturnAndBody <Generator=false>
- )
- ) ';'?
-;
-
-N4CallableConstructorDeclaration <Yield> returns N4MethodDeclaration:
- MethodParamsReturnAndBody <Generator=false> ';'?
-;
-
-fragment MethodParamsAndBody <Generator>*:
- StrictFormalParameters<Yield=Generator>
- (body=Block<Yield=Generator>)?
-;
-
-fragment MethodParamsReturnAndBody <Generator>*:
- StrictFormalParameters<Yield=Generator>
- (':' returnTypeRef=TypeRef)?
- (body=Block<Yield=Generator>)?
-;
-
-N4GetterDeclaration <Yield>:
- => ({N4GetterDeclaration}
- (declaredModifiers+=N4Modifier)*
- GetterHeader<Yield>)
- (body=Block<Yield>)? ';'?
-;
-
-fragment GetterHeader <Yield>*:
- ('get' -> LiteralOrComputedPropertyName <Yield> '(' ')' ColonSepTypeRef?)
-;
-
-N4SetterDeclaration <Yield>:
- =>({N4SetterDeclaration}
- (declaredModifiers+=N4Modifier)*
- 'set'
- ->LiteralOrComputedPropertyName <Yield>
- )
- '(' fpar=FormalParameter<Yield> ')' (body=Block<Yield>)? ';'?
-;
-
-BindingPattern <Yield>:
- ObjectBindingPattern<Yield>
- | ArrayBindingPattern<Yield>
-;
-
-ObjectBindingPattern <Yield>:
- '{' (properties+=BindingProperty<Yield,AllowType=false>
- (',' properties+=BindingProperty<Yield,AllowType=false>)*)? '}'
-;
-
-ArrayBindingPattern <Yield>:
- '['
- elements+=Elision* (
- elements+=BindingRestElement<Yield>
- (',' elements+=Elision* elements+=BindingRestElement<Yield>)*
- (',' elements+=Elision*)?
- )?
- ']'
-;
-
-BindingProperty <Yield, AllowType>:
- =>(LiteralBindingPropertyName<Yield> ':') value=BindingElement<Yield>
- | value=SingleNameBinding<Yield,AllowType>
-;
-
-fragment LiteralBindingPropertyName <Yield>*:
- declaredName=IdentifierName | declaredName=STRING | declaredName=NumericLiteralAsString
- | '[' (declaredName=SymbolLiteralComputedName<Yield> | declaredName=STRING) ']'
-;
-
-SingleNameBinding <Yield, AllowType>:
- varDecl=VariableDeclaration<In=true,Yield,AllowType>
-;
-
-BindingElement <Yield>:
- =>(nestedPattern=BindingPattern<Yield>) ('=' expression=AssignmentExpression<In=true,Yield>)?
- | varDecl=VariableDeclaration<In=true,Yield,AllowType=true>
-;
-
-BindingRestElement <Yield>:
- rest?='...'?
- (
- =>(nestedPattern=BindingPattern<Yield>)
- ('=' expression=AssignmentExpression<In=true,Yield>)?
- | varDecl=VariableDeclaration<In=true,Yield,AllowType=true>
- )
-;
-
-Elision:
- ','
-;</programlisting>
-</section>
-</chapter>
-<chapter xml:id="_jsobjects">
-<title>JSObjects</title>
-<simpara>The built-in ECMAScript Objects
-[<link linkend="ECMA11a">ECMA11a(p.S15, p.p.102)</link>] are supported and their properties are annotated with types as described in this chapter. The semantics of these properties do not change. The short description is copied from [<link linkend="ECMA11a">ECMA11a</link>] repeated here for convenience.</simpara>
-<section xml:id="_object" role="language-n4js">
-<title>Object</title>
-<simpara><literal>Object</literal> is the super type of all declared types and <literal>N4Object</literal>. It is almost similar to the JavaScript type <literal>Object</literal> except that no properties may be dynamically added to it. In order to declare a variable to which properties can be dynamically added, the <literal>Object+</literal> type has to be declared (cf.
-<xref linkend="_dynamic"/>).</simpara>
-<bridgehead xml:id="_attributes" renderas="sect3">Attributes</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>constructor:Object</literal></term>
-<listitem>
-<simpara>Returns a reference to the Object function that created the instance’s
-prototype.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="_methods-2" renderas="sect3">Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>toString():Object</literal></term>
-<listitem>
-<simpara>Returns a string representing the specified object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toLocaleString():Object</literal></term>
-<listitem>
-<simpara>Returns a string representing the object. This method is meant to be
-overridden by derived objects for locale-specific purposes.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>valueOf():Object</literal></term>
-<listitem>
-<simpara>Returns the primitive value of the specified object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>hasOwnProperty(prop:String):Boolean</literal></term>
-<listitem>
-<simpara>Returns a boolean indicating whether an object contains the specified
-property as a direct property of that object and not inherited through
-the prototype chain.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>isPrototypeOf(object:Object):Boolean</literal></term>
-<listitem>
-<simpara>Returns a boolean indication whether the specified object is in the
-prototype chain of the object this method is called upon.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>propertyIsEnumerable(prop:String):Boolean</literal></term>
-<listitem>
-<simpara>Returns a boolean indicating if the internal ECMAScript DontEnum
-attribute is set.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="_static-methods" renderas="sect3">Static Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>getPrototypeOf(object:Object):Object</literal></term>
-<listitem>
-<simpara>Returns the prototype of the specified object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>create(object:Object,properties:Object=):Object</literal></term>
-<listitem>
-<simpara>Creates a new object with the specified prototype object and properties.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>defineProperty(object:Object,prop:Object,descriptor:Object):Object</literal></term>
-<listitem>
-<simpara>Defines a new property directly on an object or modifies an existing
-property on an object and returns the object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>defineProperties(object:Object,properties:Object):Object</literal></term>
-<listitem>
-<simpara>Defines new or modifies existing properties directly on an object,
-returning the object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>seal(object:Object,properties:Object)</literal></term>
-<listitem>
-<simpara>Seals an object, preventing new properties from being added to it and
-marking all existing properties as non-configurable. Values of present
-properties can still be changed as long as they are writable.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>freeze(object:Object):Object</literal></term>
-<listitem>
-<simpara>Freezes an object: that is, prevents new properties from being added to it, prevents existing properties from being removed, prevents existing properties or their enumerability, configurability, or writability from being changed.
-In essence, the object is made effectively immutable.
-The method returns the object being frozen.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>preventExtensions(object:Object):Object</literal></term>
-<listitem>
-<simpara>Prevents new properties from ever being added to an object (i.e.
-prevents future extensions to the object).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>isSealed(object:Object):Boolean static</literal></term>
-<listitem>
-<simpara>Determine if an object is sealed.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>isFrozen(object:Object):Boolean</literal></term>
-<listitem>
-<simpara>Determine if an object is frozen.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>isExtensible(object:Object):Boolean</literal></term>
-<listitem>
-<simpara>Determines if an object is extensible (whether it can have new
-properties added to it).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>keys(object:Object):Array<String></literal></term>
-<listitem>
-<simpara>Returns an array of all own enumerable properties found upon a given
-object in the same order as that provided by a for-in loop (the
-difference being that a for-in loop enumerates properties in the
-prototype chain as well).</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_string" role="language-n4js">
-<title>String</title>
-<simpara>String is a global object that may be used to construct String
-instances and is a sub class of Object.</simpara>
-<bridgehead xml:id="string-attributes" renderas="sect3">Attributes</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>number: length</literal> </term>
-<listitem>
-<simpara>The length of a string.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="methods-1" renderas="sect3">Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>String(thing:Object=)</literal></term>
-<listitem>
-<simpara>-</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>anchor(anchorname:String):String</literal></term>
-<listitem>
-<simpara>Creates an HTML anchor.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>big():String</literal></term>
-<listitem>
-<simpara>Returns a string in a big font.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>blink():String</literal></term>
-<listitem>
-<simpara>Returns a string in a blinking string.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>bold():String</literal></term>
-<listitem>
-<simpara>Returns a string in a bold font.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>charAt(index:Number):String</literal></term>
-<listitem>
-<simpara>Returns the character at a specified position.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>charCodeAt(index:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the Unicode of the character at a specified position.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>concat(strings:String…​):String</literal></term>
-<listitem>
-<simpara>Joins two or more strings.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>equals(object:Object):Boolean</literal> </term>
-<listitem>
-<simpara>-</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>equalsIgnoreCase(object:Object):Boolean</literal> </term>
-<listitem>
-<simpara>-</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fromCharCode(num:Any…​):String</literal></term>
-<listitem>
-<simpara>Returns a string created by using the specified sequence of Unicode values.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fixed():String</literal></term>
-<listitem>
-<simpara>Returns a string as teletype text.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fontcolor(color):String</literal></term>
-<listitem>
-<simpara>Returns a string in a specified color.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>fontsize(size):String</literal></term>
-<listitem>
-<simpara>Returns a string in a specified size.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>indexOf(searchValue, fromIndex:Number=):Number</literal></term>
-<listitem>
-<simpara>Returns the position of the first occurrence of a specified string value in a string.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>italics():String</literal></term>
-<listitem>
-<simpara>Returns a string in italic.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>lastIndexOf(searchValue, fromIndex:Number=):Number</literal></term>
-<listitem>
-<simpara>Returns the position of the last occurrence of a specified string value, searching backwards from the specified position in a string.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>link(url):String</literal></term>
-<listitem>
-<simpara>Returns a string as a hyperlink.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>localeCompare(otherString):Number</literal></term>
-<listitem>
-<simpara>This method returns a number indicating whether a reference string comes before or after or is the same as the given string in sort order.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>match(search value):String</literal></term>
-<listitem>
-<simpara>Searches for a specified value in a string.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>replace(findString,newString):String</literal></term>
-<listitem>
-<simpara>Replaces some characters with some other characters in a string.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>search(search string):Number</literal></term>
-<listitem>
-<simpara>Searches a string for a specified value.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>slice(beginSlice:Number, endSclice:Number=):String</literal></term>
-<listitem>
-<simpara>Extracts a part of a string and returns the extracted part in a new string.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>small():String</literal></term>
-<listitem>
-<simpara>Returns a string in a small font.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>split(separator, howmany:Number=):Array<String></literal></term>
-<listitem>
-<simpara>Splits a string into an array of strings.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>strike():String</literal></term>
-<listitem>
-<simpara>Returns a string with a strikethrough.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>sub():String</literal></term>
-<listitem>
-<simpara>Returns a string as subscript.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>substr(start:Number,length:Number=):String</literal></term>
-<listitem>
-<simpara>Extracts a specified number of characters in a string, from a start index.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>substring(beginIndex:number,endIndex:Number=):String</literal></term>
-<listitem>
-<simpara>Extracts the characters in a string between two specified indices.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>sup():String</literal></term>
-<listitem>
-<simpara>Returns a string as superscript.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toLocaleUpperCase():String</literal></term>
-<listitem>
-<simpara>Returns a string in lowercase letters.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toString():String</literal></term>
-<listitem>
-<simpara>Returns a String value for this object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toUpperCase():String</literal></term>
-<listitem>
-<simpara>Returns a string in uppercase letters.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>valueOf():String</literal></term>
-<listitem>
-<simpara>Returns the primitive value of a String object.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="static-methods-1" renderas="sect3">Static Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>String(value:Object=)</literal></term>
-<listitem>
-<simpara>Static constructor.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_boolean" role="language-n4js">
-<title>Boolean</title>
-<simpara><literal>Boolean</literal> does not have a super class.</simpara>
-<bridgehead xml:id="static-methods-2" renderas="sect3">Static Methods</bridgehead>
-<simpara><literal>Boolean(value:Object=):Boolean</literal></simpara>
-</section>
-<section xml:id="_number" role="language-n4js">
-<title>Number</title>
-<simpara><literal>Number</literal> does not have a super class.</simpara>
-<section xml:id="_static-attributes">
-<title>Static Attributes</title>
-<variablelist>
-<varlistentry>
-<term><literal>MAX_VALUE:Number</literal></term>
-<listitem>
-<simpara>The largest representable number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>MIN_VALUE:Number</literal></term>
-<listitem>
-<simpara>The smallest representable number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>NaN:Number</literal></term>
-<listitem>
-<simpara>Special 'not a number' value.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>NEGATIVE_INFINITY:Number</literal></term>
-<listitem>
-<simpara>Special value representing negative infinity, returned on overflow.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>POSITIVE_INFINITY:Number</literal></term>
-<listitem>
-<simpara>Special value representing infinity, returned on overflow.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="methods-2" renderas="sect3">Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>toExponential(numberOfDecimals:Number=):String</literal></term>
-<listitem>
-<simpara>Converts the value of the object into an exponential notation.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toFixed(numberOfDecimals:Number=):String</literal></term>
-<listitem>
-<simpara>Formats a number to the specified number of decimals.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toPrecision(numberOfDecimals:Number=):String</literal></term>
-<listitem>
-<simpara>Converts a number into an exponential notation if it has more digits than specified.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>valueOf():Number</literal></term>
-<listitem>
-<simpara>Returns the primitive value of a Number object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toString(radix:Number=):String</literal></term>
-<listitem>
-<simpara>Returns a String value for this object. The toString method parses its first argument and attempts to return a string representation in the specified radix (base).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toLocaleString(locales: String|[String]=undefined, options: <subscript>r</subscript>NumberFormatOptions=undefined): String</literal></term>
-<listitem>
-<simpara>Returns a locale-specific String value for this object. The toLocalString accepts two optional arguments. The semantics of these arguments
-is defined in <link xl:href="https://www.ecma-international.org/ecma-402/4.0/index.html#sup-number.prototype.tolocalestring">ECMA-402 (Internationalization API Specification)</link>.
-In N4JS, the base definition does not define that method, instead Number inherits <literal>toLocaleString</literal> from Object. The specialized
-definition is found in the runtime library <literal>n4js-runtime-ecma402</literal>.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="static-methods-3" renderas="sect3">Static Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>Number(value:Object=):Number</literal></term>
-<listitem>
-<simpara>Static constructor.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-</section>
-<section xml:id="function" role="language-n4js">
-<title>Function</title>
-<simpara><literal>Function</literal> does not have a super class.</simpara>
-<bridgehead xml:id="attributes-2" renderas="sect3">Attributes</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>prototype:Object</literal></term>
-<listitem>
-<simpara>Allows the addition of properties to the instance of the object created by the constructor function.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>length:Number</literal></term>
-<listitem>
-<simpara>Specifies the number of arguments expected by the functio</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="methods-3" renderas="sect3">Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>apply(thisArg,argsArray:Array=):Object</literal></term>
-<listitem>
-<simpara>Applies the method of another object in the context of a different object (the calling object); arguments can be passed as an Array object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>call(thisArg,arg…​):Object</literal></term>
-<listitem>
-<simpara>Calls (executes) a method of another object in the context of a different object (the calling object); arguments can be passed as they are.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>bind(thisArg:Object,arg…​):Function</literal></term>
-<listitem>
-<simpara>Creates a new function that, when called, itself calls this function in the context of the provided this value with a given sequence of arguments preceding any provided when the new function was called.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_error" role="language-n4js">
-<title>Error</title>
-<simpara><literal>Error</literal> does not have a super class.</simpara>
-<bridgehead xml:id="attributes-3" renderas="sect3">Attributes</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>name:String</literal></term>
-<listitem>
-<simpara>Error name.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>message:String</literal></term>
-<listitem>
-<simpara>Error message.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="static-methods-4" renderas="sect3">Static Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>Error(message:Object=):Error</literal></term>
-<listitem>
-<simpara>Static Constructor.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_array" role="language-n4js">
-<title>Array</title>
-<simpara><literal>Array</literal> is a generic type with the type parameter <literal>E</literal> and does not have a super class.</simpara>
-<bridgehead xml:id="methods-4" renderas="sect3">Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>concat(array…​):Array<E>)</literal></term>
-<listitem>
-<simpara>Joins two or more arrays and returns the result.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>every(callback:Function):Boolean</literal></term>
-<listitem>
-<simpara>Tests whether all elements in the array pass the test implemented by the provided function. The callback will be called with 3 arguments (elementValue,elementIndex,traversedArray).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>filter(callback:Function):Array<E></literal></term>
-<listitem>
-<simpara>Creates a new array with all elements that pass the test implemented by the provided function. The callback will be called with 3 arguments (elementValue,elementIndex,traversedArray).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>forEach(callback:Function,thisArg=)</literal></term>
-<listitem>
-<simpara>Calls a function for each element in the array. The callback will be called with 3 arguments (elementValue,elementIndex,traversedArray). Optionally with a thisObject argument to use as this when executing callback.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>indexOf(searchElement,fromIndex=):Number</literal></term>
-<listitem>
-<simpara>Returns the first index at which a given element can be found in the array, or -1 if it is not present.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>join(separator=):String</literal></term>
-<listitem>
-<simpara>Puts all the elements of an array into a string. The elements are separated by a specified delimiter.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>lastIndexOf(searchElement,fromIndex=):Number</literal></term>
-<listitem>
-<simpara>Returns the last (greatest) index of an element within the array equal to the specified value. Will return -1 if none are found.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>length():Number</literal></term>
-<listitem>
-<simpara>The length returns an integer representing the length of an array.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>map(callback:Function,thisArg=):Array</literal></term>
-<listitem>
-<simpara>Creates a new array with the results of calling a provided function on every element in this array. The callback will be called with 3 arguments (elementValue,elementIndex,traversedArray). Optionally, with a thisObject argument to use as this when executing callback.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>pop():E</literal></term>
-<listitem>
-<simpara>Removes and returns the last element of an array.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>push(element…​):E</literal></term>
-<listitem>
-<simpara>Adds one or more elements to the end of an array and returns the new length.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>reverse():Array<E></literal></term>
-<listitem>
-<simpara>Reverses the order of the elements in an array.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>shift()</literal></term>
-<listitem>
-<simpara>Removes and returns the first element of an array.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>slice(start:Number,end:Number=):Array<E></literal></term>
-<listitem>
-<simpara>Returns selected elements from an existing array.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>some(callback:Function,thisArg=):Boolean</literal></term>
-<listitem>
-<simpara>Tests whether some element in the array passes the test implemented by the provided function. The callback will be called with 3 arguments (elementValue,elementIndex,traversedArray). Optionally, with a thisObject argument to use as this when executing callback.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>sort(sortByFunction:Function=):Array<E></literal></term>
-<listitem>
-<simpara>Sorts the elements of an array. The function will be called with 2 arguments (a,b).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>splice(index:Number,how many:Number,element…​):Array<E></literal></term>
-<listitem>
-<simpara>Removes and adds new elements to an array. Returns the removed elements as an Array.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toLocaleString():String</literal></term>
-<term><literal>toString():String</literal></term>
-<listitem>
-<simpara>Returns a String value for Array.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>unshift(element…​):E</literal></term>
-<listitem>
-<simpara>Adds one or more elements to the beginning of an array and returns the new length.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="static-methods-5" renderas="sect3">Static Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>Array(item:Object…​)</literal></term>
-<listitem>
-<simpara>Static constructor.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_date" role="language-n4js">
-<title>Date</title>
-<simpara><literal>Date</literal> does not have a super class.</simpara>
-<bridgehead xml:id="static-methods-6" renderas="sect3">Static Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>Date():Date</literal></term>
-<listitem>
-<simpara>Static constructor.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Date(milliseconds:Number):Date</literal></term>
-<listitem>
-<simpara>Constructor.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Date(date:Date):Date</literal></term>
-<listitem>
-<simpara>Constructor.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Date(dateString:String):Date</literal></term>
-<listitem>
-<simpara>Constructor.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Date(year:Number,month:Number,day=Number=,hour:Number=,minute:Number=,second:Number=,millisecond:Number=):Date</literal></term>
-<listitem>
-<simpara>Constructor.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>parse(dateString:String):Date</literal></term>
-<listitem>
-<simpara>Parses a string representation of a date, and returns the number of milliseconds since midnight Jan 1, 1970.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>now():Number</literal></term>
-<listitem>
-<simpara>Returns the numeric value corresponding to the current time.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>UTC(year:Number,month:Number,date:Number=,hrs:Number=,min:Number=,sec:Number=,ms:Number=):Number</literal></term>
-<listitem>
-<simpara>UTC takes comma-delimited date parameters and returns the number of milliseconds between January 1, 1970, 00:00:00, Universal Time and the time you specified.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="methods-5" renderas="sect3">Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>getDate():Number</literal></term>
-<listitem>
-<simpara>Returns the day of the month from a Date object (from 1-31).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getDay():Number</literal></term>
-<listitem>
-<simpara>Returns the day of the week from a Date object (from 0-6).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getFullYear():Number</literal></term>
-<listitem>
-<simpara>Returns the year, as a four-digit number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getHours():Number</literal></term>
-<listitem>
-<simpara>Returns the hour of a day (from 0-23).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getMilliseconds():Number</literal></term>
-<listitem>
-<simpara>Returns the milliseconds of a Date object (from 0-999).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getMinutes():Number</literal></term>
-<listitem>
-<simpara>Returns the minutes of a date (from 0-59).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getMonth():Number</literal></term>
-<listitem>
-<simpara>Returns the month from a date (from 0-11).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getSeconds():Number</literal></term>
-<listitem>
-<simpara>Returns the seconds of a date (from 0-59).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getTime():Number</literal></term>
-<listitem>
-<simpara>Returns the number of milliseconds since midnight Jan 1, 1970.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>valueOf():Number</literal></term>
-<listitem>
-<simpara>Returns the primitive value of a Date object as a number data type, the number of milliseconds since midnight 01 January, 1970 UTC. This method is functionally equivalent to the getTime method.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getTimezoneOffset():Number</literal></term>
-<listitem>
-<simpara>Returns the difference in minutes between local time and Greenwich Mean Time (GMT).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getUTCDate():Number</literal></term>
-<listitem>
-<simpara>Returns the day of the month from a date according to Universal Time (from 1-31).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getUTCDay():Number</literal></term>
-<listitem>
-<simpara>Returns the day of the week from a date according to Universal Time (from 0-6).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getUTCFullYear():Number</literal></term>
-<listitem>
-<simpara>Returns the four-digit year from a date according to Universal Time.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getUTCHours():Number</literal></term>
-<listitem>
-<simpara>Returns the hour of a date according to Universal Time (from 0-23).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getUTCMilliseconds():Number</literal></term>
-<listitem>
-<simpara>Returns the milliseconds of a date according to Universal Time (from 0-999).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getUTCMinutes():Number</literal></term>
-<listitem>
-<simpara>Returns the minutes of a date according to Universal Time (from 0-59).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getUTCMonth():Number</literal></term>
-<listitem>
-<simpara>Returns the month from a Date object according to Universal Time (from 0-11).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getUTCSeconds():Number</literal></term>
-<listitem>
-<simpara>Returns the seconds of a date according to Universal Time (from 0-59).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>getYear():Number deprecated</literal></term>
-<listitem>
-<simpara>Returns the year as a two-digit or a three/four-digit number, depending on the browser. Use getFullYear() instead!</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setDate(day):Number</literal></term>
-<listitem>
-<simpara>Sets the day of the month from a Date object (from 1-31).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setFullYear(full year, month=, day=):Number</literal></term>
-<listitem>
-<simpara>Sets the year as a four-digit number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setHours(hours,minutes=,seconds=,milis=):Number</literal></term>
-<listitem>
-<simpara>Sets the hour of a day (from 0-23).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setMilliseconds(mills):Number</literal></term>
-<listitem>
-<simpara>Sets the milliseconds of a Date object (from 0-999).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setMinutes(minutes,=seconds,=millis):Number</literal></term>
-<listitem>
-<simpara>Sets the minutes of a date (from 0-59).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setMonth" directType="Number(month,day=):Number</literal></term>
-<listitem>
-<simpara>Sets the month from a date (from 0-11).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setSeconds(seconds,millis=):number</literal></term>
-<listitem>
-<simpara>Sets the seconds of a date (from 0-59).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setTime(mills):Number</literal></term>
-<listitem>
-<simpara>Sets the number of milliseconds since midnight Jan 1, 1970.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setUTCDate(day):Number</literal></term>
-<listitem>
-<simpara>Sets the day of the month from a date according to Universal Time (from 0-6).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setUTCFullYear(fullyear,month=,day=):Number</literal></term>
-<listitem>
-<simpara>Sets the four-digit year from a date according to Universal Time.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setUTCHours(hours,minutes=,seconds=,millis=):Number</literal></term>
-<listitem>
-<simpara>Sets the hour of a date according to Universal Time (from 0-23).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setUTCMilliseconds(mills):Number</literal></term>
-<listitem>
-<simpara>Sets the milliseconds of a date according to Universal Time (from 0-999).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setUTCMinutes(minutes,seconds=,millis=):Number</literal></term>
-<listitem>
-<simpara>Sets the minutes of a date according to Universal Time time (from 0-59).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setUTCMonth(month,day=):Number</literal></term>
-<listitem>
-<simpara>Sets the month from a Date object according to Universal Time (from 0-11).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setUTCSeconds(seconds,millis=):Number</literal></term>
-<listitem>
-<simpara>Sets the seconds of a date according to Universal Time (from 0-59).</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>setYear(year):Number deprecated</literal></term>
-<listitem>
-<simpara>Sets the year, as a two-digit or a three/four-digit number, depending on the browser. Use setFullYear() instead!!</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toDateString():String</literal></term>
-<listitem>
-<simpara>Returns the date portion of a Date object in readable form.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toLocaleDateString(locales: String|[String]=undefined, options: <subscript>r</subscript>DateTimeFormatOptions=undefined): String</literal></term>
-<listitem>
-<simpara>Converts a Date object, using locales and options as defined in DateTimeFormat of ECMA-402 (Internationalization API), to a string and returns the date and time portion.
-The toLocalString accepts two optional arguments. The semantics of these arguments is defined in
-<link xl:href="https://www.ecma-international.org/ecma-402/4.0/index.html#sup-date.prototype.tolocaledatestring">ECMA-402 (Internationalization API Specification)</link>.
-The specialized definition is found in the runtime library <literal>n4js-runtime-ecma402</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toLocaleString(locales: String|[String]=undefined, options: <subscript>r</subscript>DateTimeFormatOptions=undefined): String</literal></term>
-<listitem>
-<simpara>Converts a Date object, using locales and options as defined in DateTimeFormat of ECMA-402 (Internationalization API), to a string.
-The toLocalString accepts two optional arguments. The semantics of these arguments is defined in
-<link xl:href="https://www.ecma-international.org/ecma-402/4.0/index.html#sup-date.prototype.tolocalestring">ECMA-402 (Internationalization API Specification)</link>.
-In N4JS, the base definition does not define that method, instead Date inherits <literal>toLocaleString</literal> from Object. The specialized
-definition is found in the runtime library <literal>n4js-runtime-ecma402</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toLocaleTimeString(locales: String|[String]=undefined, options: <subscript>r</subscript>DateTimeFormatOptions=undefined): String</literal></term>
-<listitem>
-<simpara>Converts a Date object, using locales and options as defined in DateTimeFormat of ECMA-402 (Internationalization API), to a string and returns the time portion.
-The semantics of these arguments is defined in
-<link xl:href="https://www.ecma-international.org/ecma-402/4.0/index.html#sup-date.prototype.tolocaletimestring">ECMA-402 (Internationalization API Specification)</link>.
-The specialized definition is found in the runtime library <literal>n4js-runtime-ecma402</literal>.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toString():String</literal></term>
-<listitem>
-<simpara>Returns a String value for this object.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toTimeString():String</literal></term>
-<listitem>
-<simpara>Returns the time portion of a Date object in readable form.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>toUTCString():String</literal></term>
-<listitem>
-<simpara>Converts a Date object, according to Universal Time, to a string.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_math" role="language-n4js">
-<title>Math</title>
-<simpara><literal>Math</literal> is not instantiable and only provides static properties and methods.</simpara>
-<section xml:id="static-attributes-1">
-<title>Static Attributes</title>
-<variablelist>
-<varlistentry>
-<term><literal>E:Number</literal></term>
-<listitem>
-<simpara>Euler’s constant and the base of natural logarithms, approximately 2.718.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>LN2:Number</literal></term>
-<listitem>
-<simpara>Natural logarithm of 2, approximately 0.693.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>LN10:Number</literal></term>
-<listitem>
-<simpara>Natural logarithm of 10, approximately 2.302.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>LOG2E:Number</literal></term>
-<listitem>
-<simpara>Base 2 logarithm of E, approximately 1.442.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>LOG10E:Number</literal></term>
-<listitem>
-<simpara>Base 10 logarithm of E, approximately 0.434.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>PI:Number</literal></term>
-<listitem>
-<simpara>Ratio of the circumference of a circle to its diameter, approximately 3.14159.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>SQRT1_2:Number</literal></term>
-<listitem>
-<simpara>Square root of 1/2; equivalently, 1 over the square root of 2, approximately 0.707.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>SQRT2:Number</literal></term>
-<listitem>
-<simpara>Square root of 2, approximately 1.414.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="static-methods-7" renderas="sect3">Static Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>abs(x):Number</literal></term>
-<listitem>
-<simpara>Returns the absolute value of a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>acos(x:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the arccosine of a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>asinx:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the arcsine of a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>atan(x:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the arctangent of a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>atan2(y:Number,x:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the arctangent of the quotient of its arguments.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>ceil(x):Number</literal></term>
-<listitem>
-<simpara>Returns the smallest integer greater than or equal to a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>cos(x):Number</literal></term>
-<listitem>
-<simpara>Returns the arctangent of the quotient of its arguments.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>exp(x):Number</literal></term>
-<listitem>
-<simpara>Returns Enumber, where number is the argument, and E is Euler’s constant (2.718…​), the base of the natural logarithm.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>floor(x):Number</literal></term>
-<listitem>
-<simpara>Returns the largest integer less than or equal to a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>log(x):Number</literal></term>
-<listitem>
-<simpara>Returns the natural logarithm (loge, also ln) of a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>max(value…​):Number</literal></term>
-<listitem>
-<simpara>Returns the largest of zero or more numbers.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>min(value…​):Number</literal></term>
-<listitem>
-<simpara>Returns the smallest of zero or more numbers.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>pow(base:Number,exponent:Number):Number</literal></term>
-<listitem>
-<simpara>Returns base to the exponent power, that is, baseexponent.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>random():Number</literal></term>
-<listitem>
-<simpara>Returns a pseudorandom number between 0 and 1.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>round(x:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the value of a number rounded to the nearest integer.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>sin(x:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the sine of a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>sqrt(x:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the positive square root of a number.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>tan(x:Number):Number</literal></term>
-<listitem>
-<simpara>Returns the tangent of a number.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-</section>
-<section xml:id="_regexp" role="language-n4js">
-<title>RegExp</title>
-<simpara><literal>RegExp</literal> does not have a super class.</simpara>
-<bridgehead xml:id="attributes-4" renderas="sect3">Attributes</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>global:Boolean</literal></term>
-<listitem>
-<simpara>Whether to test the regular expression against all possible matches in a string, or only against the first.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>ignoreCase:Boolean</literal></term>
-<listitem>
-<simpara>Whether to ignore case while attempting a match in a string.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>lastIndex:Number</literal></term>
-<listitem>
-<simpara>The index at which to start the next match.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>multiline:Boolean</literal></term>
-<listitem>
-<simpara>Whether or not to search in strings across multiple lines.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>source:String</literal></term>
-<listitem>
-<simpara>The text of the pattern.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="methods-6" renderas="sect3">Methods</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>exec(str:String):Array</literal></term>
-<listitem>
-<simpara>Executes a search for a match in its string parameter.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>test(str:String):Boolean</literal></term>
-<listitem>
-<simpara>Tests for a match in its string parameter.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-</section>
-<section xml:id="_json" role="language-n4js">
-<title>JSON</title>
-<simpara><literal>JSON</literal> is a global object and a subclass of <literal>Object</literal>. Its functionality is provided by two static methods.
-It is not possible to create new instances of type JSON.</simpara>
-<bridgehead xml:id="attributes-5" renderas="sect3">Attributes</bridgehead>
-<simpara>The JSON object does not define own properties.</simpara>
-<bridgehead xml:id="methods-7" renderas="sect3">Methods</bridgehead>
-<simpara>The JSON object does not define own methods.</simpara>
-<bridgehead xml:id="static-methods-8" renderas="sect3">Static Methods</bridgehead>
-<simpara>The parse function parses a JSON text (a JSON-formatted String) and
-produces an ECMAScript value. The JSON format is a restricted form of
-ECMAScript literal. JSON objects are realized as ECMAScript objects.
-JSON arrays are realized as ECMAScript arrays. JSON strings, numbers,
-booleans, and null are realized as ECMAScript Strings, Numbers,
-Booleans, and null. For detailed information see [<link linkend="ECMA11a">ECMA11a(p.S15.12.2)</link>]</simpara>
-<simpara>The optional reviver parameter is a function that takes two parameters
-(key and value). It can filter and transform the results. It is called
-with each of the key/value pairs produced by the parse and its return
-value is used instead of the original value. If it returns what it
-received, the structure is not modified. If it returns then the property
-is deleted from the result.</simpara>
-<simpara>The stringify function returns a String in JSON format representing an
-ECMAScript value. It can take three parameters. The first parameter is
-required. The value parameter is an ECMAScript value which is usually an
-object or array, although it can also be a String, Boolean, Number or
-null.</simpara>
-<simpara>The optional replacer parameter is either a function that alters the way
-objects and arrays are stringified or an array of Strings and Numbers
-that act as a white list for selecting the object properties that will
-be stringified.</simpara>
-<simpara>The optional space parameter is a String or Number that allows the
-result to have whitespace injected into it to improve human readability.</simpara>
-<simpara>For detailed information see [<link linkend="ECMA11a">ECMA11a(p.S15.12.3)</link>].</simpara>
-</section>
-</chapter>
-<chapter xml:id="_n4js-objects">
-<title>N4JS Objects</title>
-<section xml:id="_reflection-model">
-<title>Reflection Model</title>
-<simpara>N4JS provided metadata for reflection (and introspection). This
-information is available via instances of some reflection model classes
-(described below) attached to types and (in some cases) functions.</simpara>
-<simpara>The following class diagrams shows the defined classes. Note that for
-performance reasons, the actual structure may vary from the model.</simpara>
-<figure xml:id="fig-n4js-reflection-classes">
-<title>N4JS Reflection Classes</title>
-<mediaobject>
-<imageobject>
-<imagedata fileref="chapters/a03_n4jsobjects/fig/cd_reflectionModel.svg"/>
-</imageobject>
-<textobject><phrase>cd reflectionModel</phrase></textobject>
-</mediaobject>
-</figure>
-<simpara>Remark: This section is work in progress. The final goal is to provide a
-metamodel similar to Ecore, but we will only add new features if needed.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/**
- * Base class for all N4 reflective elements.
- */
-export public abstract class N4Element extends Object {
- /**
- * Annotations attached to this element.
- */
- public Array<N4Annotation> annotations = [];
-
- /**
- * The origin string formed as <ID-VERSION>, where ID is containing project artefact id, and VERSION is its version
- */
- public String origin;
-
- /**
- * Returns true if an annotation with the given name is attached to the element.
- */
- public boolean hasAnnotation(string name) {
- return !!this.anyAnnotation(name)
- }
-
- /**
- * Returns any annotation with the given name attached to the element, or null if no such annotation is found.
- */
- public N4Annotation anyAnnotation(string name) {
- for (var i=this.annotations.length-1; i>=0; i--) {
- var a = this.annotations[i];
- if (a) {
- return a;
- }
- }
- return null;
- }
- /**
- * Returns all annotations with the given name attached to the element, or an empty array if no such annotations are found.
- */
- public Array<N4Annotation> allAnnotations(string name) {
- return this.annotations.filter(function(a){return a.name==name});
- }
-}
-
-/**
- * Base class for all reflective classes with a name.
- */
-export public abstract class N4NamedElement extends N4Element {
- /**
- * The simple name of a named element.
- */
- public string name;
-}
-
-/**
- * Base class for all reflective classes describing a type (declaration).
- */
-export public abstract class N4Type extends N4NamedElement {
- /**
- * The FQN of the type.
- */
- public string fqn;
-
- /**
- * Returns true if this N4Class describes an N4-class declaration.
- */
- public boolean get isClass() { return false; }
-
- /**
- * Returns true if this N4Class describes an N4-interface declaration.
- */
- public boolean get isInterface() { return false; }
-
- /**
- * Returns true if this N4Class describes an N4-enumeration declaration.
- */
- public boolean get isEnum() { return false; }
-}
-
-/**
- * Base class for meta types of classes or interfaces.
- */
-export public abstract class N4Classifier extends N4Type {
-
- /**
- * The N4Class of the super type, may be null if super type is a not an N4Class.
- */
- public N4Class n4superType;
-
- /**
- * Array of the FQN of all (transitively) implemented interfaces, i.e. interfaces directly implemented by this class, its super
- * class or interfaces extended by directly implemented interfaces.
- */
- public Array<string> allImplementedInterfaces;
-
- /**
- * Array of all owned members, that is members defined in the class directly.
- * This field is private as it is an internal detail, members are accessed via methods defined in this class.
- */
- private Array<N4Member> ownedMembers;
-
- /**
- * Array of all consumed members, that is members mixed into the classifier via interface implementation and default methods.
- * This field is private as it is an internal detail, members are accessed via methods defined in this class.
- */
- private Array<N4Member> consumedMembers;
-
- /**
- * Only used internally, must not be called by client.
- */
- protected constructor(@Spec ~~this spec) {}
-
- /**
- * Returns all members defined by this class directly, consumed, and inherited. The boolean flags control which members are returned.
- *
- * @param consumed if set, consumed members are returned as well (false by default)
- * @param inherited if set, inherited members are returned as well (false by default)
- * @param _static if set, static members are returned, otherwise instance members (false by default).
- * @return array of members, may be empty but never null
- */
- public Array<? extends N4Member> members(boolean? consumed, boolean? inherited, boolean? _static) {
- return null; // TODO
- }
-
- /**
- * Returns all members defined in this classifier (or inherited) with an annotation
- * of given name attached to it. The boolean flags control which methods are returned.
- *
- * @param name name of annotation to be used as filter
- * @param consumed if set, consumed members are returned as well (false by default)
- * @param inherited if set, inherited members are returned as well (false by default)
- * @param _static if set, static members are returned, otherwise instance members (false by default).
- * @return array of members, may be empty but never null
- */
- public Array<? extends N4Member> membersWithAnnotation(string name, boolean? consumed, boolean? inherited, boolean? _static) {
- return null; // TODO
- }
-
- /**
- * Returns all data fields defined by this class directly, consumed, and inherited. The boolean flags control which data fields are returned.
- *
- * @param consumed if set, consumed data fields are returned as well (false by default)
- * @param inherited if set, inherited data fields are returned as well (false by default)
- * @param _static if set, static data fields are returned, otherwise instance members (false by default).
- * @return array of data fields, may be empty but never null
- */
- public Array<? extends N4DataField> dataFields(boolean? consumed, boolean? inherited, boolean? _static) {
- return null; // TODO
- }
-
- /**
- * Returns all data fields defined in this classifier (or inherited) with an annotation
- * of given name attached to it. The boolean flags control which data fields are returned.
- *
- * @param name name of annotation to be used as filter
- * @param consumed if set, consumed data fields are returned as well (false by default)
- * @param inherited if set, inherited data fields are returned as well (false by default)
- * @param _static if set, static data fields are returned, otherwise instance members (false by default).
- * @return array of data fields, may be empty but never null
- */
- public Array<? extends N4DataField> dataFieldsWithAnnotation(string name, boolean? consumed, boolean? inherited, boolean? _static) {
- return null; // TODO
- }
-
- /**
- * Returns all methods defined by this class directly, consumed, and inherited. The boolean flags control which methods are returned.
- *
- * @param consumed if set, consumed methods are returned as well (false by default)
- * @param inherited if set, inherited methods are returned as well (false by default)
- * @param _static if set, static methods are returned, otherwise instance members (false by default).
- * @return array of methods, may be empty but never null
- */
- public Array<? extends N4Method> methods(boolean? consumed, boolean? inherited, boolean? _static) {
- return null; // TODO
- }
-
- /**
- * Returns all methods defined in this classifier (or inherited) with an annotation
- * of given name attached to it. The boolean flags control which methods are returned.
- *
- * @param name name of annotation to be used as filter
- * @param consumed if set, consumed methods are returned as well (false by default)
- * @param inherited if set, inherited methods are returned as well (false by default)
- * @param _static if set, static methods are returned, otherwise instance members (false by default).
- * @return array of methods, may be empty but never null
- */
- public Array<? extends N4Method> methodsWithAnnotation(string name, boolean? consumed, boolean? inherited, boolean? _static) {
- return null; // TODO
- }
-
-
-}
-
-/**
- * Meta information of an n4 class.
- */
-export @Final public class N4Class extends N4Classifier {
-
- /**
- * Returns the N4Class instance for a given n4object. This is similar to
- * {@code n4object.constructor.n4type}, however it can also be used in interfaces
- * to get reflective information of the implementor.
- */
- public static N4Class of(N4Object n4object) {
- return n4object.constructor.n4type
- }
-
- /**
- * Returns true if this N4Class describes an N4-class declaration.
- */
- @Override
- public boolean get isClass() { return true; }
-}
-
-
-/**
- * Meta information of an n4 interface.
- */
-export @Final public class N4Interface extends N4Classifier {
- /**
- * Returns true if this N4Class describes an N4-interface declaration.
- */
- @Override
- public boolean get isInterface() { return true; }
-}
-
-/**
- * Description of a member, that is a method or field.
- */
-export public abstract class N4Member extends N4Element {
- public string name;
-}
-
-/**
- * Description of a method.
- */
-export @Final public class N4Method extends N4Member {
- public Function jsFunction;
-}
-
-/**
- * Description of a simple data field.
- */
-export @Final public class N4DataField extends N4Member {
-}
-
-/**
- * Description of an accessor, that is a getter or setter.
- */
-export @Final public class N4Accessor extends N4Member {
- /**
- * Flag indicating whether accessor is a getter or setter, internal detail.
- */
- private boolean getter;
- /**
- * Returns true if accessor is a getter.
- */
- public boolean isGetter() { return this.getter; }
- /**
- * Returns true if accessor is a setter.
- */
- public boolean isSetter() { return ! this.getter; }
-}
-
-/**
- * Description of an N4Enum
- */
-export @Final public class N4EnumType extends N4Type {
- /**
- * Returns true if this N4Clasifier describes an N4-enumeration declaration.
- */
- @Override public boolean get isEnum() { return true; }
- /**
- * Returns the N4EnumType instance for a given enum literal. This is similar to
- * {@code n4enum.constructor.n4type}.
- */
- public static N4EnumType of(N4Enum n4enum) {
- return n4enum.constructor.n4type
- }
-}
-
-/**
- * Base class for all enumeration, literals are assumed to be static constant fields of concrete subclasses.
- */
-export public abstract class N4Enum extends Object {
-
- /**
- * Returns the name of a concrete literal
- */
- public abstract string get name();
-
- /**
- * Returns the value of a concrete literal. If no value is
- * explicitly set, it is similar to the name.
- */
- public abstract string get value()
-
- /**
- * Returns a string representation of a concrete literal, it returns
- * the same result as value()
- */
- @Override public string toString() { return this.value }
-
- /**
- * Returns the enum class object of this enum literal for reflection.
- * The very same meta class object can be retrieved from the enumeration type directly.
- */
- public abstract N4Enum get n4Enum()
-
- /**
- * Natively overridden by concrete enums.
- */
- public static Array<? extends N4Enum> get values() { return null; }
-
- /**
- * Natively overridden by concrete enums.
- */
- public static N4Enum valueByName(string name) { return null; }
-
- /**
- * Returns the meta class object of this class for reflection.
- * The very same meta class object can be retrieved from an instance by calling
- * <code>instance.constructor.n4type</code>
- */
- public static N4EnumType get n4type() { return null; }
-}
-
-/**
- * Annotation with value.
- */
-export @Final public class N4Annotation extends Object {
- public string name;
- public union{string,number} value;
-}
-
-/**
- * The base class for all instances of n4 classes.
- */
-export public class N4Object {
- /**
- * Returns the meta class object of this class for reflection.
- * The very same meta class object can be retrieved from an instance by calling
- * <code>instance.constructor.n4type</code>
- */
- // defined in types model, added by $makeClass:
- // public static N4Class get n4type() { return null; }
-}</programlisting>
-</section>
-<section xml:id="_error-types">
-<title>Error Types</title>
-<simpara>N4JS provides additional Error types as subtypes of <literal>Error</literal>.</simpara>
-<section xml:id="_n4apinotimplemented" role="language-n4js">
-<title>N4ApiNotImplemented</title>
-<simpara>Considering API definitions and concrete implementations of those APIs
-the error <literal>N4-Api-Not-Implemented-Error</literal> is introduced to specifically report missing implementations.
-Instances of this error type are inserted internally during the
-transpilation of API-implementing projects. Whenever a difference to the
-API in form of a missing implementation is encountered, the transpiler
-will insert stub-code throwing an instance of <literal>N4-Api-Not-Implemented-Error</literal>.</simpara>
-<simpara>API-testing projects can catch those errors and act accordingly. This
-enables tracking of completeness of implementations by counting the
-occasions an <literal>N4-Api-NotImplemented-Error</literal> was encountered.</simpara>
-<programlisting language="n4js" linenumbering="unnumbered">/**
- * Error type reporting a not implemented situation.
- */
-public class N4ApiNotImplementedError extends Error { }</programlisting>
-</section>
-</section>
-</chapter>
-<appendix xml:id="_acronyms">
-<title>Acronyms</title>
-<informaltable xml:id="AC" role="language-bash" frame="all" rowsep="1" colsep="1">
-<tgroup cols="4">
-<colspec colname="col_1" colwidth="8.3333*"/>
-<colspec colname="col_2" colwidth="41.6666*"/>
-<colspec colname="col_3" colwidth="8.3333*"/>
-<colspec colname="col_4" colwidth="41.6668*"/>
-<tbody>
-<row>
-<entry align="center" valign="top"><simpara><literal>CDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Compile-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>RDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Run-Time Dependency</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>LDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Load-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>IDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Initialization-Time Dependency</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>EDep</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Execution-Time Dependency</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>ANTLR</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">ANother Tool for Language Recognition</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>API</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Application Programming Interface</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>AST</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Abstract Syntax Tree</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>ASI</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Automatic Semicolon Insertion</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>BNF</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Backus-Naur Form</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>CLI</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Command Line Interface (including a headless compiler and runner.)</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>DI</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Dependency Injection</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>DIC</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">DI Component</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>DOM</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Document Object Model</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>DSL</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Domain Specific Language</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>EBNF</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Extended Backus-Naur Form</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>EMF</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Eclipse Modeling Framework <anchor xml:id="EMF" xreflabel="[EMF]"/></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>FQN</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Fully Qualified Name</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>GLB</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Greatest Lower Bound, also known as <emphasis>infimum</emphasis></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>GCST</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Greatest Common Sub Type, also known as <emphasis>meet</emphasis></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>IDE</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Integrated Development Environment</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>IDL</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Interface Definition Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>LSP</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Liskov Substitution Principle [<link linkend="Martin96b">Martin96b</link>]</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>LUB</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Least Upper Bound, also known as <emphasis>supremum</emphasis></emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>LCST</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Least Common Super Type, also known as <emphasis>join</emphasis></emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>N4JS</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4JS for JavaScript</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>N4JSED</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4JS Environment Definition</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>N4JSIDE</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">N4JS Integrated Development Environment (Eclipse-based IDE for all N4JS related languages and projects)</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>VM</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Virtual Machine</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>XML</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Extensible Markup Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>XSLT / XSL</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">XSL Transformations</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>XSL</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Extensible Stylesheet Language</emphasis></simpara></entry>
-</row>
-<row>
-<entry align="center" valign="top"><simpara><literal>WYSIWYG</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">What You See Is What You Get</emphasis></simpara></entry>
-<entry align="center" valign="top"><simpara><literal>WLOG</literal></simpara></entry>
-<entry align="left" valign="top"><simpara><emphasis role="strong">Without loss of generality</emphasis></simpara></entry>
-</row>
-</tbody>
-</tgroup>
-</informaltable>
-</appendix>
-<appendix xml:id="sec:License">
-<title>License</title>
-<simpara>This specification and the accompanying materials is made available
-under the terms of the Eclipse Public License v1.0 which accompanies
-this distribution, and is available at <link xl:href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</link></simpara>
-<bridgehead xml:id="_eclipse-public-license-v-1-0" renderas="sect2">Eclipse Public License - v 1.0</bridgehead>
-<simpara>THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE
-PUBLIC LICENSE (<literal>AGREEMENT</literal>). ANY USE, REPRODUCTION OR DISTRIBUTION OF
-THE PROGRAM CONSTITUTES RECIPIENT’S ACCEPTANCE OF THIS AGREEMENT.</simpara>
-<bridgehead xml:id="_1-definitions" renderas="sect3">1. DEFINITIONS</bridgehead>
-<variablelist>
-<varlistentry>
-<term><literal>Contribution</literal> means: </term>
-<listitem>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>in the case of the initial Contributor, the initial code and
-documentation distributed under this Agreement, and</simpara>
-</listitem>
-<listitem>
-<simpara>in the case of each subsequent Contributor:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>changes to the Program, and</simpara>
-</listitem>
-<listitem>
-<simpara>additions to the Program;</simpara>
-<simpara>where such changes and/or additions to the Program originate from and
-are distributed by that particular Contributor. A Contribution
-’originates’ from a Contributor if it was added to the Program by such
-Contributor itself or anyone acting on such Contributor’s behalf.
-Contributions do not include additions to the Program which:</simpara>
-<orderedlist numeration="lowerroman">
-<listitem>
-<simpara>are separate modules of software distributed in conjunction with the Program
-under their own license agreement, and</simpara>
-</listitem>
-<listitem>
-<simpara>are not derivative works of the Program.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Contributor</literal></term>
-<listitem>
-<simpara>means any person or entity that distributes the Program.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Licensed Patents</literal> </term>
-<listitem>
-<simpara>mean patent claims licensable by a Contributor
-which are necessarily infringed by the use or sale of its Contribution
-alone or when combined with the Program.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Program</literal> </term>
-<listitem>
-<simpara>means the Contributions distributed in accordance with this
-Agreement.</simpara>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term><literal>Recipient</literal> </term>
-<listitem>
-<simpara>means anyone who receives the Program under this
-Agreement, including all Contributors.</simpara>
-</listitem>
-</varlistentry>
-</variablelist>
-<bridgehead xml:id="_2-grant-of-rights" renderas="sect3">2. GRANT OF RIGHTS</bridgehead>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>Subject to the terms of this Agreement, each Contributor hereby
-grants Recipient a non-exclusive, worldwide, royalty-free copyright
-license to reproduce, prepare derivative works of, publicly display,
-publicly perform, distribute and sublicense the Contribution of such
-Contributor, if any, and such derivative works, in source code and
-object code form.</simpara>
-</listitem>
-<listitem>
-<simpara>Subject to the terms of this Agreement, each Contributor hereby
-grants Recipient a non-exclusive, worldwide, royalty-free patent license
-under Licensed Patents to make, use, sell, offer to sell, import and
-otherwise transfer the Contribution of such Contributor, if any, in
-source code and object code form. This patent license shall apply to the
-combination of the Contribution and the Program if, at the time the
-Contribution is added by the Contributor, such addition of the
-Contribution causes such combination to be covered by the Licensed
-Patents. The patent license shall not apply to any other combinations
-which include the Contribution. No hardware per se is licensed
-hereunder.</simpara>
-</listitem>
-<listitem>
-<simpara>Recipient understands that although each Contributor grants the
-licenses to its Contributions set forth herein, no assurances are
-provided by any Contributor that the Program does not infringe the
-patent or other intellectual property rights of any other entity. Each
-Contributor disclaims any liability to Recipient for claims brought by
-any other entity based on infringement of intellectual property rights
-or otherwise. As a condition to exercising the rights and licenses
-granted hereunder, each Recipient hereby assumes sole responsibility to
-secure any other intellectual property rights needed, if any. For
-example, if a third party patent license is required to allow Recipient
-to distribute the Program, it is Recipient’s responsibility to acquire
-that license before distributing the Program.</simpara>
-</listitem>
-<listitem>
-<simpara>Each Contributor represents that to its knowledge it has sufficient
-copyright rights in its Contribution, if any, to grant the copyright
-license set forth in this Agreement.</simpara>
-</listitem>
-</orderedlist>
-<bridgehead xml:id="_3-requirements" renderas="sect3">3. REQUIREMENTS</bridgehead>
-<simpara>A Contributor may choose to distribute the Program in object code form
-under its own license agreement, provided that:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>it complies with the terms and conditions of this Agreement; and</simpara>
-</listitem>
-<listitem>
-<simpara>its license agreement:</simpara>
-<orderedlist numeration="loweralpha">
-<listitem>
-<simpara>effectively disclaims on behalf of all Contributors all warranties
-and conditions, express and implied, including warranties or conditions
-of title and non-infringement, and implied warranties or conditions of
-merchantability and fitness for a particular purpose;</simpara>
-</listitem>
-<listitem>
-<simpara>effectively excludes on behalf of all Contributors all liability for
-damages, including direct, indirect, special, incidental and
-consequential damages, such as lost profits;</simpara>
-</listitem>
-<listitem>
-<simpara>states that any provisions which differ from this Agreement are
-offered by that Contributor alone and not by any other party; and</simpara>
-</listitem>
-<listitem>
-<simpara>states that source code for the Program is available from such
-Contributor, and informs licensees how to obtain it in a reasonable
-manner on or through a medium customarily used for software exchange.</simpara>
-</listitem>
-</orderedlist>
-</listitem>
-</orderedlist>
-<simpara>When the Program is made available in source code form:</simpara>
-<orderedlist numeration="arabic">
-<listitem>
-<simpara>it must be made available under this Agreement; and</simpara>
-</listitem>
-<listitem>
-<simpara>a copy of this Agreement must be included with each copy of the
-Program.</simpara>
-</listitem>
-</orderedlist>
-<simpara>Contributors may not remove or alter any copyright notices contained
-within the Program.</simpara>
-<simpara>Each Contributor must identify itself as the originator of its
-Contribution, if any, in a manner that reasonably allows subsequent
-Recipients to identify the originator of the Contribution.</simpara>
-<bridgehead xml:id="_4-commercial-distribution" renderas="sect3">4. COMMERCIAL DISTRIBUTION</bridgehead>
-<simpara>Commercial distributors of software may accept certain responsibilities
-with respect to end users, business partners and the like. While this
-license is intended to facilitate the commercial use of the Program, the
-Contributor who includes the Program in a commercial product offering
-should do so in a manner which does not create potential liability for
-other Contributors. Therefore, if a Contributor includes the Program in
-a commercial product offering, such Contributor (<literal>Commercial
-Contributor</literal>) hereby agrees to defend and indemnify every other
-Contributor (<literal>Indemnified Contributor</literal>) against any losses, damages
-and costs (collectively <literal>Losses</literal>) arising from claims, lawsuits and
-other legal actions brought by a third party against the Indemnified
-Contributor to the extent caused by the acts or omissions of such
-Commercial Contributor in connection with its distribution of the
-Program in a commercial product offering. The obligations in this
-section do not apply to any claims or Losses relating to any actual or
-alleged intellectual property infringement. In order to qualify, an
-Indemnified Contributor must: a) promptly notify the Commercial
-Contributor in writing of such claim, and b) allow the Commercial
-Contributor to control, and cooperate with the Commercial Contributor
-in, the defense and any related settlement negotiations. The Indemnified
-Contributor may participate in any such claim at its own expense.</simpara>
-<simpara>For example, a Contributor might include the Program in a commercial
-product offering, Product X. That Contributor is then a Commercial
-Contributor. If that Commercial Contributor then makes performance
-claims, or offers warranties related to Product X, those performance
-claims and warranties are such Commercial Contributor’s responsibility
-alone. Under this section, the Commercial Contributor would have to
-defend claims against the other Contributors related to those
-performance claims and warranties, and if a court requires any other
-Contributor to pay any damages as a result, the Commercial Contributor
-must pay those damages.</simpara>
-<bridgehead xml:id="_5-no-warranty" renderas="sect3">5. NO WARRANTY</bridgehead>
-<simpara>EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED
-ON AN <literal>AS IS</literal> BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
-EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES
-OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR
-A PARTICULAR PURPOSE. Each Recipient is solely responsible for
-determining the appropriateness of using and distributing the Program
-and assumes all risks associated with its exercise of rights under this
-Agreement , including but not limited to the risks and costs of program
-errors, compliance with applicable laws, damage to or loss of data,
-programs or equipment, and unavailability or interruption of operations.</simpara>
-<bridgehead xml:id="_6-disclaimer-of-liability" renderas="sect3">6. DISCLAIMER OF LIABILITY</bridgehead>
-<simpara>EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR
-ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT,
-INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING
-WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF
-LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
-NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR
-DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
-HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</simpara>
-<bridgehead xml:id="_7-general" renderas="sect3">7. GENERAL</bridgehead>
-<simpara>If any provision of this Agreement is invalid or unenforceable under
-applicable law, it shall not affect the validity or enforceability of
-the remainder of the terms of this Agreement, and without further action
-by the parties hereto, such provision shall be reformed to the minimum
-extent necessary to make such provision valid and enforceable.</simpara>
-<simpara>If Recipient institutes patent litigation against any entity (including
-a cross-claim or counterclaim in a lawsuit) alleging that the Program
-itself (excluding combinations of the Program with other software or
-hardware) infringes such Recipient’s patent(s), then such Recipient’s
-rights granted under Section 2(b) shall terminate as of the date such
-litigation is filed.</simpara>
-<simpara>All Recipient’s rights under this Agreement shall terminate if it fails
-to comply with any of the material terms or conditions of this Agreement
-and does not cure such failure in a reasonable period of time after
-becoming aware of such noncompliance. If all Recipient’s rights under
-this Agreement terminate, Recipient agrees to cease use and distribution
-of the Program as soon as reasonably practicable. However, Recipient’s
-obligations under this Agreement and any licenses granted by Recipient
-relating to the Program shall continue and survive.</simpara>
-<simpara>Everyone is permitted to copy and distribute copies of this Agreement,
-but in order to avoid inconsistency the Agreement is copyrighted and may
-only be modified in the following manner. The Agreement Steward reserves
-the right to publish new versions (including revisions) of this
-Agreement from time to time. No one other than the Agreement Steward has
-the right to modify this Agreement. The Eclipse Foundation is the
-initial Agreement Steward. The Eclipse Foundation may assign the
-responsibility to serve as the Agreement Steward to a suitable separate
-entity. Each new version of the Agreement will be given a distinguishing
-version number. The Program (including Contributions) may always be
-distributed subject to the version of the Agreement under which it was
-received. In addition, after a new version of the Agreement is
-published, Contributor may elect to distribute the Program (including
-its Contributions) under the new version. Except as expressly stated in
-Sections 2(a) and 2(b) above, Recipient receives no rights or licenses
-to the intellectual property of any Contributor under this Agreement,
-whether expressly, by implication, estoppel or otherwise. All rights in
-the Program not expressly granted under this Agreement are reserved.</simpara>
-<simpara>This Agreement is governed by the laws of the State of New York and the
-intellectual property laws of the United States of America. No party to
-this Agreement will bring a legal action under this Agreement more than
-one year after the cause of action arose. Each party waives its rights
-to a jury trial in any resulting litigation.</simpara>
-</appendix>
-<appendix xml:id="_bibliography">
-<title>Bibliography</title>
-<simpara><anchor xml:id="ECMA15a" xreflabel="[ECMA15a]"/>ECMA. (2015). <emphasis>ECMAScript 2015 Language Specification</emphasis>. Retrieved from <link xl:href="http://www.ecma-international.org/ecma-262/6.0/index.html">http://www.ecma-international.org/ecma-262/6.0/index.html</link></simpara>
-<simpara><anchor xml:id="ECMA11a" xreflabel="[ECMA11a]"/>(2011). <emphasis>ECMAScript Language Specification</emphasis>. Retrieved from <link xl:href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">http://www.ecma-international.org/publications/standards/Ecma-262.htm</link></simpara>
-<simpara><anchor xml:id="Pierce02a" xreflabel="[Pierce02a]"/>Pierce, Benjamin C.. (2002). <emphasis>Types and Programming Languages</emphasis>. </simpara>
-<simpara><anchor xml:id="Gosling15a" xreflabel="[Gosling15a]"/>Gosling, James and Joy, Bill and Steele, Guy and Bracha, Gilad and Buckley, Alex. (2015). <emphasis>The Java Language Specification. Java SE 8 Edition</emphasis>. Retrieved from <link xl:href="http://docs.oracle.com/javase/specs/jls/se8/jls8.pdf">http://docs.oracle.com/javase/specs/jls/se8/jls8.pdf</link></simpara>
-<simpara><anchor xml:id="Gosling12a" xreflabel="[Gosling12a]"/>Gosling, James and Joy, Bill and Steele, Guy and Bracha, Gilad and Buckley, Alex. (2012). <emphasis>The Java Language Specification. Java SE 7 Edition</emphasis>. Retrieved from <link xl:href="http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf">http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf</link></simpara>
-<simpara><anchor xml:id="Nielson99a" xreflabel="[Nielson99a]"/>Nielson, Flemming and Nielson, HanneRiis. (1999). <emphasis>Type and Effect Systems</emphasis>. Retrieved from <link xl:href="http://dx.doi.org/10.1007/3-540-48092-7_6">http://dx.doi.org/10.1007/3-540-48092-7_6</link></simpara>
-<simpara><anchor xml:id="Crary02a" xreflabel="[Crary02a]"/>Crary, Karl and Weirich, Stephanie and Morrisett, Greg. (2002). <emphasis>Intensional polymorphism in type-erasure semantics</emphasis>. Retrieved from <link xl:href="http://journals.cambridge.org/article_S0956796801004282">http://journals.cambridge.org/article_S0956796801004282</link></simpara>
-<simpara><anchor xml:id="Igarashi01a" xreflabel="[Igarashi01a]"/>Igarashi, Atsushi and Pierce, Benjamin C. and Wadler, Philip. (2001). <emphasis>Featherweight Java: a minimal core calculus for Java and GJ</emphasis>. </simpara>
-<simpara><anchor xml:id="Torgersen05a" xreflabel="[Torgersen05a]"/>Torgersen, Mads and Ernst, Erik and Hansen, Christian Plesner. (2005). <emphasis>Wild FJ</emphasis>. Retrieved from <link xl:href="http://homepages.inf.ed.ac.uk/wadler/fool/program/14.html">http://homepages.inf.ed.ac.uk/wadler/fool/program/14.html</link></simpara>
-<simpara><anchor xml:id="Cameron08b" xreflabel="[Cameron08b]"/>Cameron, Nicholas and Drossopoulou, Sophia and Ernst, Erik. (2008). <emphasis>A Model for Java with Wildcards</emphasis>. Retrieved from <link xl:href="http://dx.doi.org/10.1007/978-3-540-70592-5_2">http://dx.doi.org/10.1007/978-3-540-70592-5_2</link></simpara>
-<simpara><anchor xml:id="Cameron09a" xreflabel="[Cameron09a]"/>Cameron, Nicholas. (2009). <emphasis>Existential Types for Variance — Java Wildcards and Ownership Types</emphasis>. Retrieved from <link xl:href="http://www.doc.ic.ac.uk/~ncameron/papers/cameron_thesis.pdf">http://www.doc.ic.ac.uk/~ncameron/papers/cameron_thesis.pdf</link></simpara>
-<simpara><anchor xml:id="Summers10a" xreflabel="[Summers10a]"/>Summers, Alexander J. and Cameron, Nicholas and Dezani-Ciancaglini, Mariangiola and Drossopoulou, Sophia. (2010). <emphasis>Towards a semantic model for Java wildcards</emphasis>. </simpara>
-<simpara><anchor xml:id="Wehr08a" xreflabel="[Wehr08a]"/>Wehr, Stefan and Thiemann, Peter. (2008). <emphasis>Subtyping Existential Types</emphasis>. Retrieved from <link xl:href="http://www.informatik.uni-freiburg.de/~wehr/publications/Wehr_Subtyping_existential_types.pdf">http://www.informatik.uni-freiburg.de/~wehr/publications/Wehr_Subtyping_existential_types.pdf</link></simpara>
-<simpara><anchor xml:id="Igarashi07a" xreflabel="[Igarashi07a]"/>Igarashi, Atsushi and Nagira, Hideshi. (2007). <emphasis>Union Types for Object-Oriented Programming</emphasis>. Retrieved from <link xl:href="http://www.jot.fm/issues/issue_2007_02/article3/">http://www.jot.fm/issues/issue_2007_02/article3/</link></simpara>
-<simpara><anchor xml:id="King13a" xreflabel="[King13a]"/>King, Gavin. (2013). <emphasis>The Ceylon Language</emphasis>. Red Hat, Inc.. Retrieved from <link xl:href="http://ceylon-lang.org/documentation/1.0/spec/pdf/ceylon-language-specification.pdf">http://ceylon-lang.org/documentation/1.0/spec/pdf/ceylon-language-specification.pdf</link></simpara>
-<simpara><anchor xml:id="Laurent12a" xreflabel="[Laurent12a]"/>Laurent, Olivier. (2012). <emphasis>Intersection types with subtyping by means of cut elimination</emphasis>. </simpara>
-<simpara><anchor xml:id="W3C:Steen:14:XL" xreflabel="[W3C:Steen:14:XL]"/>Steen, Hallvord and Aubourg, Julian and van Kesteren, Anne and Song, Jungkee. (2014). <emphasis>XMLHttpRequest Level 1</emphasis>. </simpara>
-<simpara><anchor xml:id="Dart13a" xreflabel="[Dart13a]"/>Dart Team. (2013). <emphasis>Dart Programming Language Specification</emphasis>. Retrieved from <link xl:href="http://www.dartlang.org/docs/spec/latest/dart-language-specification.pdf">http://www.dartlang.org/docs/spec/latest/dart-language-specification.pdf</link></simpara>
-<simpara><anchor xml:id="OMG14a" xreflabel="[OMG14a]"/>OMG. (2014). <emphasis>Interface Definition Language</emphasis>. Object Management Group. Retrieved from <link xl:href="http://www.omg.org/cgi-bin/doc?formal/2014-03-01.pdf">http://www.omg.org/cgi-bin/doc?formal/2014-03-01.pdf</link></simpara>
-<simpara><anchor xml:id="W3C12a" xreflabel="[W3C12a]"/>W3C. (2012). <emphasis>Web IDL Specification</emphasis>. Retrieved from <link xl:href="http://www.w3.org/TR/2012/CR-WebIDL-20120419/">http://www.w3.org/TR/2012/CR-WebIDL-20120419/</link></simpara>
-<simpara><anchor xml:id="Kuizinas14a" xreflabel="[Kuizinas14a]"/>Kuizinas, Gajus. (2014). <emphasis>The Definitive Guide to the JavaScript Generators</emphasis>. Retrieved from <link xl:href="http://gajus.com/blog/2/the-definetive-guide-to-the-javascript-generators">http://gajus.com/blog/2/the-definetive-guide-to-the-javascript-generators</link></simpara>
-<simpara><anchor xml:id="West06a" xreflabel="[West06a]"/>West, Mike. (2006). <emphasis>Scope in JavaScript</emphasis>. Retrieved from <link xl:href="http://www.digital-web.com/articles/scope_in_javascript/">http://www.digital-web.com/articles/scope_in_javascript/</link></simpara>
-<simpara><anchor xml:id="ECMA18a" xreflabel="[ECMA18a]"/>ECMA. (2018). <emphasis>ECMAScript 2018 Language Specification</emphasis>. Retrieved from <link xl:href="http://www.ecma-international.org/ecma-262/9.0/index.html">http://www.ecma-international.org/ecma-262/9.0/index.html</link></simpara>
-<simpara><anchor xml:id="MozillaJSRef" xreflabel="[MozillaJSRef]"/><emphasis>JavaScript Reference</emphasis>. Retrieved from <link xl:href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference</link></simpara>
-<simpara><anchor xml:id="Fowler04b" xreflabel="[Fowler04b]"/>Fowler, Martin. (2004). <emphasis>Inversion of Control Containers and the Dependency Injection pattern</emphasis>. Retrieved from <link xl:href="http://martinfowler.com/articles/injection.html">http://martinfowler.com/articles/injection.html</link></simpara>
-<simpara><anchor xml:id="Prasanna09a" xreflabel="[Prasanna09a]"/>Prasanna, Dhanji R. (2009). <emphasis>Dependency Injection: Design Patterns Using Spring and Guice</emphasis>. </simpara>
-<simpara><anchor xml:id="Zhu13a" xreflabel="[Zhu13a]"/>Zhu, He and Jagannathan, Suresh. (2013). <emphasis>Compositional and Lightweight Dependent Type Inference for ML</emphasis>. Retrieved from <link xl:href="http://dx.doi.org/10.1007/978-3-642-35873-9_19">http://dx.doi.org/10.1007/978-3-642-35873-9_19</link></simpara>
-<simpara><anchor xml:id="Hudli13a" xreflabel="[Hudli13a]"/>Hudli, Shrinidhi R. and Hudli, Raghu V.. (2013). <emphasis>A Verification Strategy for Dependency Injection</emphasis>. </simpara>
-<simpara><anchor xml:id="Lesiecki08a" xreflabel="[Lesiecki08a]"/>Lesiecki, Nicholas. (2008). <emphasis>Dependency injection with Guice</emphasis>. Retrieved from <link xl:href="http://www.ibm.com/developerworks/library/j-guice/">http://www.ibm.com/developerworks/library/j-guice/</link></simpara>
-<simpara><anchor xml:id="Betts13a" xreflabel="[Betts13a]"/>Betts, Dominic and Melnik, Grigori and Simonazzi, Fernando and Subramanian, Mani. (2013). <emphasis>Dependency Injection with Unity</emphasis>. </simpara>
-<simpara><anchor xml:id="Knol13a" xreflabel="[Knol13a]"/>Knol, Alex. (2013). <emphasis>Dependency injection with AngularJS</emphasis>. </simpara>
-<simpara><anchor xml:id="Dagger" xreflabel="[Dagger]"/><emphasis>Dagger, Project Website</emphasis>. Retrieved from <link xl:href="http://square.github.io/dagger/">http://square.github.io/dagger/</link></simpara>
-<simpara><anchor xml:id="ECMA12a" xreflabel="[ECMA12a]"/>(2012). <emphasis>ECMAScript Internationalization API Specification</emphasis>. Retrieved from <link xl:href="http://www.ecma-international.org/publications/standards/Ecma-402.htm">http://www.ecma-international.org/publications/standards/Ecma-402.htm</link></simpara>
-<simpara><anchor xml:id="Martin96b" xreflabel="[Martin96b]"/>Martin, Robert C. (1996). <emphasis>The Liskov Substitution Principle</emphasis>. Retrieved from <link xl:href="http://www.objectmentor.com/publications/lsp.pdf">http://www.objectmentor.com/publications/lsp.pdf</link></simpara>
-</appendix>
-</book>
\ No newline at end of file
diff --git a/spec/annotations.html b/spec/annotations.html
index 5a749a7..d2cb441 100644
--- a/spec/annotations.html
+++ b/spec/annotations.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1079,7 +1079,7 @@
<p>If no matching error is found, the annotation itself will issue an error.</p>
</div>
<div id="ex:IDEBUG" class="exampleblock">
-<div class="title">Example 97. IDEBUG Example</div>
+<div class="title">Example 98. IDEBUG Example</div>
<div class="content">
<div class="paragraph">
<p>In the following code snippet, two errors are to be transformed to warnings.</p>
@@ -1157,7 +1157,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/appendix_a_acronyms.html b/spec/appendix_a_acronyms.html
index 2630b45..2b6e854 100644
--- a/spec/appendix_a_acronyms.html
+++ b/spec/appendix_a_acronyms.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -958,7 +958,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/appendix_b_license.html b/spec/appendix_b_license.html
index a514546..e1850a5 100644
--- a/spec/appendix_b_license.html
+++ b/spec/appendix_b_license.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1144,7 +1144,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/appendix_c_bibliography.html b/spec/appendix_c_bibliography.html
index f2ec876..d273e7b 100644
--- a/spec/appendix_c_bibliography.html
+++ b/spec/appendix_c_bibliography.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1138,7 +1138,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/classifiers.html b/spec/classifiers.html
index 805b3b3..3d223a8 100644
--- a/spec/classifiers.html
+++ b/spec/classifiers.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1201,7 +1201,7 @@
In Java, however, more constraints exist, (for example, methods of interfaces must be public).</p>
</div>
<div class="exampleblock">
-<div class="title">Example 29. Simple Class</div>
+<div class="title">Example 30. Simple Class</div>
<div class="content">
<div class="paragraph">
<p>This first example shows a very simple class with a field, a constructor and a method.</p>
@@ -1222,7 +1222,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 30. Extend and implement</div>
+<div class="title">Example 31. Extend and implement</div>
<div class="content">
<div class="paragraph">
<p>The following example demonstrate how a class can extend a superclass and implement an interface.</p>
@@ -1607,7 +1607,7 @@
<math xmlns="http://www.w3.org/1998/Math/MathML"><mo>∀</mo><mi>m</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>o</mi><mi>w</mi><mi>n</mi><mi>e</mi><mi>d</mi><mi>M</mi><mi>e</mi><mi>t</mi><mi>h</mi><mi>o</mi><mi>d</mi><mi>s</mi><mi>:</mi><mi>m</mi><mo>.</mo><mi>n</mi><mi>a</mi><mi>m</mi><mi>e</mi><msup><mo>≠</mo><mi>'</mi></msup><mi>c</mi><mi>o</mi><mi>n</mi><mi>s</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>o</mi><msup><mi>r</mi><mi>'</mi></msup></math>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 31. Simple Interfaces</div>
+<div class="title">Example 32. Simple Interfaces</div>
<div class="content">
<div class="paragraph">
<p>The following example shows the syntax for defining interfaces.
@@ -1765,7 +1765,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 32. Generic Type Definition and Usage as Type of Variable</div>
+<div class="title">Example 33. Generic Type Definition and Usage as Type of Variable</div>
<div class="content">
<div class="paragraph">
<p>This example demonstrates how to define a generic type and how to refer to it in a variable definition.</p>
@@ -1803,7 +1803,7 @@
<p>In line 3, the type variable <code>T</code> of the generic class <code>Container</code> is bound to <code>string</code>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 33. Binding of type variables with multiple types</div>
+<div class="title">Example 34. Binding of type variables with multiple types</div>
<div class="content">
<div class="paragraph">
<p>For a given generic class <code>G</code></p>
@@ -2038,7 +2038,7 @@
</div>
</div>
<div id="ex:use-site-declaration-variance" class="exampleblock">
-<div class="title">Example 34. Use-site declaration of variance</div>
+<div class="title">Example 35. Use-site declaration of variance</div>
<div class="content">
<div class="paragraph">
<p>For illustration purposes, let’s compare use-site and definition-site declaration of variance.
@@ -2618,7 +2618,7 @@
<p>Default methods in interfaces, cf. <a href="#_default-methods-in-interfaces">Default Methods in Interfaces</a>, may also be declared <code>@Final</code>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 35. Final Methods in Interfaces</div>
+<div class="title">Example 36. Final Methods in Interfaces</div>
<div class="content">
<div class="paragraph">
<p>If a method in an interface is provided with a body, it may be declared final.
@@ -2935,7 +2935,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 36. Field name conflicts with structural member name</div>
+<div class="title">Example 37. Field name conflicts with structural member name</div>
<div class="content">
<div class="paragraph">
<p>The situation described in <a href="#Req-IDE-58">[Req-IDE-58]</a> is demonstrated in the following code fragment:</p>
@@ -3145,7 +3145,7 @@
<p>The following examples illustrate further details of other use cases of spec constructors.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 37. Anonymous Interface in Constructor</div>
+<div class="title">Example 38. Anonymous Interface in Constructor</div>
<div class="content">
<div class="paragraph">
<p>The base class <code>A</code> in the examples redefines the constructor already defined in <code>N4Object</code>. This is not
@@ -3171,7 +3171,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 38. Spec Object and Subclasses</div>
+<div class="title">Example 39. Spec Object and Subclasses</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -3230,7 +3230,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 39. Superfluous Properties in @Spec Constructors</div>
+<div class="title">Example 40. Superfluous Properties in @Spec Constructors</div>
<div class="content">
<div class="paragraph">
<p>Each non-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></math> field has to be set in the constructor via the <math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>with</mtext></mstyle></math> to the parameter otherwise properties are <em>not</em> used to set non-<math xmlns="http://www.w3.org/1998/Math/MathML"><mstyle mathvariant="monospace"><mtext>public</mtext></mstyle></math> fields.</p>
@@ -3282,7 +3282,7 @@
<p>The following example illustrates this restriction.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 40. Interface fields that cannot be initialized via @Spec constructors</div>
+<div class="title">Example 41. Interface fields that cannot be initialized via @Spec constructors</div>
<div class="content">
<div class="listingblock">
<div class="title">Inf.n4jsd</div>
@@ -3450,7 +3450,7 @@
It shows a small class hierarchy using covariant constructors, <code>Cls</code> and <code>Cls2</code>, together with a helper function <code>createAnother</code> that creates and returns a new instance of the same type as its argument <code>value</code>.</p>
</div>
<div id="ex:covariant_constructors" class="exampleblock">
-<div class="title">Example 41. Covariant Constructors</div>
+<div class="title">Example 42. Covariant Constructors</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -3489,7 +3489,7 @@
<p>The next example illustrates how to use <code>@CovariantConstructor</code> with interfaces and shows a behavior that might be surprising at first sight.</p>
</div>
<div id="ex:covariant-constructors-in-interfaces" class="exampleblock">
-<div class="title">Example 42. Covariant Constructors in Interfaces</div>
+<div class="title">Example 43. Covariant Constructors in Interfaces</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -3804,7 +3804,7 @@
<p>Notes with regard to syntax: Although ECMAScript 6 does not define fields in classes, it defines getter and setter methods similarly (cf. [<a href="appendix_c_bibliography.html#ECMA15a">ECMA15a(p.S13.3, p.p.209)</a>]).</p>
</div>
<div class="exampleblock">
-<div class="title">Example 43. Getter and Setter</div>
+<div class="title">Example 44. Getter and Setter</div>
<div class="content">
<div class="paragraph">
<p>The getter and setter implementations usually reference data fields internally.
@@ -4427,7 +4427,7 @@
<p>It is even possible to call a static field accessor or method of a class using dynamic polymorphism, as demonstrated in the following example:</p>
</div>
<div id="ex:Polymorphism_and_static_methods" class="exampleblock">
-<div class="title">Example 44. Static members of classes, inheritance and polymorphism</div>
+<div class="title">Example 45. Static members of classes, inheritance and polymorphism</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -4467,7 +4467,7 @@
depending on the declared type of the receiver (and not its value):</p>
</div>
<div class="exampleblock">
-<div class="title">Example 45. Static members in Java</div>
+<div class="title">Example 46. Static members in Java</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -4535,7 +4535,7 @@
Compare the following example to <a href="types.html#_polymorphism-and-static-methods">Static Polymorphism</a> for classes above:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 46. Static members of interfaces</div>
+<div class="title">Example 47. Static members of interfaces</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -4913,7 +4913,7 @@
We always use the <code>@Override</code> annotation.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 47. Method Consumption</div>
+<div class="title">Example 48. Method Consumption</div>
<div class="content">
<div class="paragraph">
<p><a href="#tab:methodConsumption">Consumption of methods</a> shows simple examples of above rules.
@@ -5000,7 +5000,7 @@
</dl>
</div>
<div class="exampleblock">
-<div class="title">Example 48. Field and Field Initializer Consumption</div>
+<div class="title">Example 49. Field and Field Initializer Consumption</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -5195,7 +5195,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 49. Declaration Site Structural Typing</div>
+<div class="title">Example 50. Declaration Site Structural Typing</div>
<div class="content">
<div class="paragraph">
<p>The following snippet demonstrates the effect of definition-site structural types by comparing them to
@@ -5300,7 +5300,7 @@
Nested structural types are evaluated on the fly when doing subtype checks.</p>
</div>
<div id="ex:nested-structural-typing-strategies" class="exampleblock">
-<div class="title">Example 50. Nested Structural Typing Strategies</div>
+<div class="title">Example 51. Nested Structural Typing Strategies</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -5319,7 +5319,7 @@
<p>The following example demonstrates the effect of the structural type modifiers:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 51. Effect of structural type modifiers on use-site</div>
+<div class="title">Example 52. Effect of structural type modifiers on use-site</div>
<div class="content">
<div class="paragraph">
<p>Let’s assume the type defined on the left.
@@ -5473,7 +5473,6 @@
</tr>
</tbody>
</table>
-<div style="page-break-after: always;"></div>
<div class="paragraph">
<p>Note that even if a type is defined without the structural modifier, it is not possible to use <code>instanceof</code> for variables declared as structural, as shown in the next example:</p>
</div>
@@ -5526,6 +5525,16 @@
</tr>
</tbody>
</table>
+</div>
+</div>
+<div class="openblock requirement">
+<div class="content">
+<div class="paragraph">
+<p><a id="Req-IDE-78701"></a><strong>Req. IDE-78701:</strong> <a href="#Req-IDE-78701">Nominal and structural typing spec attributes</a> (ver. 1)</p>
+</div>
+<div class="paragraph">
+<p>Within this spec, we define the following attributes of a type reference <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi></math>:</p>
+</div>
<div class="ulist">
<ul>
<li>
@@ -5543,6 +5552,14 @@
<li>
<p>If a type is referenced with the structural initializer field type modifier <code>~i~</code>, then the property <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>I</mi><mi>n</mi><mi>i</mi><mi>t</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi></math> is true.</p>
</li>
+<li>
+<p>We use <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math> to simply refer any structural typing, i.e.+
+<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mo>=</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mo>∨</mo><mi>T</mi><mo>.</mo><mi>r</mi><mi>e</mi><mi>f</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi><mi>F</mi><mi>i</mi><mi>e</mi><mi>l</mi><mi>d</mi><mo>∨</mo></math>T.refStructuralReadOnlyField \lor T.refStructuralWriteOnlyField || T.refStructuralInitField || T.defStructural$</p>
+</li>
+<li>
+<p>We use <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>N</mi><mi>o</mi><mi>m</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi></math> as the opposite of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math>, i.e.<br>
+<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>N</mi><mi>o</mi><mi>m</mi><mi>i</mi><mi>n</mi><mi>a</mi><mi>l</mi><mo>=</mo><mo>¬</mo><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math></p>
+</li>
</ul>
</div>
<div class="paragraph">
@@ -5706,7 +5723,7 @@
applied.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 52. Use-Site Structural Typing</div>
+<div class="title">Example 53. Use-Site Structural Typing</div>
<div class="content">
<div class="paragraph">
<p>The following example demonstrates the effect of the structural (field) modifier, used in this case for function parameters.</p>
@@ -5729,7 +5746,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 53. Structural types variable and instanceof operator</div>
+<div class="title">Example 54. Structural types variable and instanceof operator</div>
<div class="content">
<div class="paragraph">
<p>It is possible to use a variable typed with a structural version of a type on the left hand side of the <code>instanceof</code> operator, as demonstrated in this example:</p>
@@ -5858,7 +5875,7 @@
The already-initialized <code>@Final</code> fields can be either omitted from, or can be re-initialized via, an initializer field typing <code>@Spec</code> style constructor.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 54. Subtype relationship between structural field typing</div>
+<div class="title">Example 55. Subtype relationship between structural field typing</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -6322,7 +6339,7 @@
<p>It is important to note that it is valid to use the <code>ProvidesInitializer</code> annotation for setters in <code>n4js</code> files and not only definition files.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 55. Setters with <code>@ProvidesInitializer</code> treated as optional</div>
+<div class="title">Example 56. Setters with <code>@ProvidesInitializer</code> treated as optional</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -6357,7 +6374,7 @@
visibility.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 56. Access modifier in structural typing</div>
+<div class="title">Example 57. Access modifier in structural typing</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -6469,7 +6486,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 57. Additional optional members in structural typing</div>
+<div class="title">Example 58. Additional optional members in structural typing</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -6491,7 +6508,7 @@
Hence, type variables must not be augmented with additional structural members like in the following example.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 58. Forbidden additional structural members on type variables</div>
+<div class="title">Example 59. Forbidden additional structural members on type variables</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -6507,7 +6524,7 @@
However, constraints like this should be rather stated using an explicit interface like in the example below.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 59. Use explicitly defined Interfaces</div>
+<div class="title">Example 60. Use explicitly defined Interfaces</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -6530,7 +6547,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/components.html b/spec/components.html
index 066d5f0..4c0ed9b 100644
--- a/spec/components.html
+++ b/spec/components.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1253,7 +1253,7 @@
</dl>
</div>
<div class="exampleblock">
-<div class="title">Example 102. Module Filters</div>
+<div class="title">Example 103. Module Filters</div>
<div class="content">
<div class="paragraph">
<p>A simple and a source-container-specific module filter in the <code>n4js</code> section of a package.json file.</p>
@@ -1393,14 +1393,14 @@
by default.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 103. A package.json file with N4JS-specific properties.</div>
+<div class="title">Example 104. A package.json file with N4JS-specific properties.</div>
<div class="content">
<div class="paragraph">
<p>The following example illustrates how to use the N4JS-related package.json properties.</p>
</div>
<div class="listingblock">
<div class="content">
-<pre class="highlight"><code>{
+<pre class="highlight"><code class="language-n4js" data-lang="n4js">{
"name": "SampleProject",
"version": "0.0.1",
"author": "Enfore AG",
@@ -1692,7 +1692,7 @@
<div class="listingblock">
<div class="title">Package.json: Important properties for type definition projects</div>
<div class="content">
-<pre class="highlight"><code>{
+<pre class="highlight"><code class="language-n4js" data-lang="n4js">{
"n4js": {
"projectType": "definition"
"definesPackage": "..."
@@ -2054,7 +2054,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/conversions_and_reflection.html b/spec/conversions_and_reflection.html
index f03954e..a5703d8 100644
--- a/spec/conversions_and_reflection.html
+++ b/spec/conversions_and_reflection.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -984,7 +984,7 @@
That is, in most cases, no extra hint is passed to <code>DefaultValue</code>. Thus <code>valueOf</code> usually takes precedence over toString as demonstrated in the following example:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 70. Auto-Conversion</div>
+<div class="title">Example 71. Auto-Conversion</div>
<div class="content">
<div class="paragraph">
<p>Assume some classes and corresponding instances defined as follows:</p>
@@ -1160,7 +1160,7 @@
<p>In order to avoid errors at runtime, the <code>instanceof</code> operator defines appropriate constraints, see <a href="expressions.html#_relational-expression">Relational Expression</a> for details.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 71. Type Check Example</div>
+<div class="title">Example 72. Type Check Example</div>
<div class="content">
<div class="paragraph">
<p>Given the following classes and variable:</p>
@@ -1263,7 +1263,7 @@
the constructor of <code>C</code> available, for example because the constructor is not accessible.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 72. Reflection with <code>N4class</code></div>
+<div class="title">Example 73. Reflection with <code>N4class</code></div>
<div class="content">
<div class="paragraph">
<p>This example demonstrates how these reflective features are accessed:</p>
@@ -1299,7 +1299,7 @@
They are not defined in a module, thus their <a href="appendix_a_acronyms.html#_acronyms">FQN</a> returns only their simple name.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 73. Reflection with Built-In Types</div>
+<div class="title">Example 74. Reflection with Built-In Types</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1337,7 +1337,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 74. N4Class.of</div>
+<div class="title">Example 75. N4Class.of</div>
<div class="content">
<div class="paragraph">
<p>The type has a method to retrieve the meta-information from instances (i.e. or enumeration literals using )
@@ -1505,7 +1505,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/expressions.html b/spec/expressions.html
index cd7b864..f695f22 100644
--- a/spec/expressions.html
+++ b/spec/expressions.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -937,7 +937,7 @@
Type inference heuristics and explanations are provided in the next section.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 75. This in Unrestricted Mode</div>
+<div class="title">Example 76. This in Unrestricted Mode</div>
<div class="content">
<div class="paragraph">
<p>In unrestricted mode, <code>this</code> is bound to the receiver.
@@ -969,7 +969,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 76. This in strict mode</div>
+<div class="title">Example 77. This in strict mode</div>
<div class="content">
<div class="paragraph">
<p>In strict mode, <code>this</code> is bound to the receiver.
@@ -1003,7 +1003,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 77. This in N4JS mode</div>
+<div class="title">Example 78. This in N4JS mode</div>
<div class="content">
<div class="paragraph">
<p>As in strict mode, <code>this</code> is bound to the receiver and if there is no receiver, it is bound to <code>undefined</code>. So the example above is also true for N4JS mode.
@@ -1169,7 +1169,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 78. Effect of Nominal This Type</div>
+<div class="title">Example 79. Effect of Nominal This Type</div>
<div class="content">
<div class="paragraph">
<p>Given the following declaration</p>
@@ -1209,7 +1209,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 79. This and Function Declaration</div>
+<div class="title">Example 80. This and Function Declaration</div>
<div class="content">
<div class="paragraph">
<p>This example demonstrates the usage of functions annotated with <code>@This</code>.
@@ -1238,7 +1238,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 80. This and Function Expressions</div>
+<div class="title">Example 81. This and Function Expressions</div>
<div class="content">
<div class="paragraph">
<p>In this example a function is created via a function expression.
@@ -1623,7 +1623,7 @@
<p>Note that <code>typeof [1,2,3]</code> does not return <code>Array<number></code> (as ECMAScript is not aware of the generic array type), but <code>Object</code>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 81. Array Type Inference</div>
+<div class="title">Example 82. Array Type Inference</div>
<div class="content">
<div class="paragraph">
<p>The type for all variables declared in this example is inferred to <code>Array<string></code>:</p>
@@ -1905,7 +1905,7 @@
<div class="sect4">
<h5 id="_scoping-and-linking"><a class="anchor" href="#_scoping-and-linking"></a><a class="link" href="#_scoping-and-linking">8.1.5.2. Scoping and linking</a></h5>
<div class="exampleblock">
-<div class="title">Example 82. Scoping and linking</div>
+<div class="title">Example 83. Scoping and linking</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1982,7 +1982,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 83. Parenthesized Expression Type Examples</div>
+<div class="title">Example 84. Parenthesized Expression Type Examples</div>
<div class="content">
<div class="paragraph">
<p>In the following listing, the type of the plain expressions is equivalent to the parenthesized versions:</p>
@@ -2198,7 +2198,7 @@
<p>Although index access is very limited, it is still possible to use immediate instances of <code>Object</code> in terms of a map (but this applies only to index access, not the dot notation):</p>
</div>
<div class="exampleblock">
-<div class="title">Example 84. Object as Map</div>
+<div class="title">Example 85. Object as Map</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -2362,7 +2362,7 @@
<p>to <a href="#new-expression-3">3</a> It is not possible to refer to union or intersection at that location. So this is not explicitly denied here since it is not possible anyway.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 85. Abstract classes and construction</div>
+<div class="title">Example 86. Abstract classes and construction</div>
<div class="content">
<div class="paragraph">
<p>The following examples demonstrates the usage of abstract classes and constructor types, to make the first two constraints more clearer:</p>
@@ -2531,7 +2531,7 @@
See <a href="#_property-accessors">Property Accessors</a> for semantics and type inference.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 86. Generic Method Invocation</div>
+<div class="title">Example 87. Generic Method Invocation</div>
<div class="content">
<div class="paragraph">
<p>This examples demonstrate how to explicitly
@@ -2859,7 +2859,7 @@
<p>Adding two integers (int) leads to a number, since the result may not be represented as an (JavaScript) int anymore.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 87. Type of addition expression</div>
+<div class="title">Example 88. Type of addition expression</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -3056,7 +3056,7 @@
The compiler rewrites the code to make this work.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 88. <code>instanceof</code> with Interface</div>
+<div class="title">Example 89. <code>instanceof</code> with Interface</div>
<div class="content">
<div class="paragraph">
<p>The following example demonstrates the use of the operator with an interface.
@@ -3322,7 +3322,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 89. Type of Conditional Expressions</div>
+<div class="title">Example 90. Type of Conditional Expressions</div>
<div class="content">
<div class="paragraph">
<p>Given the following declarations:</p>
@@ -3502,7 +3502,7 @@
<p>All expressions will be evaluated even though only the value of the last expression will be the result.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 90. Comma Expression</div>
+<div class="title">Example 91. Comma Expression</div>
<div class="content">
<div class="paragraph">
<p>Assignment expressions preceed comma expressions:</p>
@@ -3544,7 +3544,7 @@
there are two use cases for keyword <code>super</code>: super member access and super constructor calls.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 91. Super Keyword</div>
+<div class="title">Example 92. Super Keyword</div>
<div class="content">
<div class="paragraph">
<p>Two use cases for keyword super:</p>
@@ -3730,7 +3730,7 @@
This is important in particular for static methods as demonstrated in the following example:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 92. Super Call in Static Methods</div>
+<div class="title">Example 93. Super Call in Static Methods</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -4014,7 +4014,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/extended_fetaures.html b/spec/extended_fetaures.html
index d9a4bc4..f2ef13a 100644
--- a/spec/extended_fetaures.html
+++ b/spec/extended_fetaures.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1165,7 +1165,7 @@
(injector of the DIComponent annotated with <code>@WithParentInjector</code>).</p>
</div>
<div class="exampleblock">
-<div class="title">Example 98. Simple DIComponents Relation</div>
+<div class="title">Example 99. Simple DIComponents Relation</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1225,7 +1225,7 @@
</div>
</div>
<div id="ex:complex-dicomponents-relations" class="exampleblock">
-<div class="title">Example 99. Complex DIComponents Relations</div>
+<div class="title">Example 100. Complex DIComponents Relations</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1449,7 +1449,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 100. Simple Field Injection</div>
+<div class="title">Example 101. Simple Field Injection</div>
<div class="content">
<div class="paragraph">
<p><a href="#ex:field-injection">Simple Field Injection</a> demonstrates simple field injection using default bindings.
@@ -3111,7 +3111,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 101. Static polyfill</div>
+<div class="title">Example 102. Static polyfill</div>
<div class="content">
<div class="paragraph">
<p><a href="#ex:staticpolyfill-genmod">Static Polyfill, Genmod</a> shows an example of generated code.
@@ -3216,7 +3216,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/functions.html b/spec/functions.html
index 8b17c1b..1956fe3 100644
--- a/spec/functions.html
+++ b/spec/functions.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1092,7 +1092,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 60. Function type conformance</div>
+<div class="title">Example 61. Function type conformance</div>
<div class="content">
<div class="paragraph">
<p>The following incomplete snippet demonstrates the usage of two function variables <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>1</mn></math> and <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>f</mi><mn>2</mn></math>, in which <math xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>f</mi><mn>2</mn></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow><mo><</mo><mi>:</mi><mrow><mo>[</mo><mspace width="-0.167em"/><mrow><mo>[</mo></mrow></mrow><mrow><mi>f</mi><mn>1</mn></mrow><mrow><mrow><mo>]</mo></mrow><mspace width="-0.167em"/><mo>]</mo></mrow></math> must hold true according to the aforementioned constraints.
@@ -1115,7 +1115,7 @@
<p>The type of <code>this</code> can be explicitly set via the <code>@This</code> annotation.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 61. Function Subtyping</div>
+<div class="title">Example 62. Function Subtyping</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1138,7 +1138,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 62. Subtyping with function types</div>
+<div class="title">Example 63. Subtyping with function types</div>
<div class="content">
<div class="paragraph">
<p>If classes A, B, and C are defined as previously mentioned, i.e. <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo><</mo><mi>:</mi><mi>B</mi><mo><</mo><mi>:</mi><mi>A</mi></math>, then
@@ -1300,7 +1300,7 @@
Where a particular type variable is used, on co- or contra-variant position, is not relevant:</p>
</div>
<div class="exampleblock">
-<div class="title">Example 63. Bounded type variable at co-variant position in function type</div>
+<div class="title">Example 64. Bounded type variable at co-variant position in function type</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1546,7 +1546,7 @@
This supertype contains all common properties of these two subtypes, that is, all properties of <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>F</mi><mi>u</mi><mi>n</mi><mi>c</mi><mi>t</mi><mi>i</mi><mi>o</mi><mi>n</mi><mi>E</mi><mi>x</mi><mi>p</mi><mi>r</mi><mi>e</mi><mi>s</mi><mi>s</mi><mi>i</mi><mi>o</mi><mi>n</mi></math>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 64. Function Declaration with Type Annotation</div>
+<div class="title">Example 65. Function Declaration with Type Annotation</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1632,7 +1632,7 @@
This is demonstrated in the next example.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 65. Inference Of Function Expression’s Signature</div>
+<div class="title">Example 66. Inference Of Function Expression’s Signature</div>
<div class="content">
<div class="paragraph">
<p>In general, <code>{function():any}</code> is a subtype of <code>{function():void}</code> (cf. <a href="#_function-type">Function Type</a>).
@@ -1809,7 +1809,7 @@
Take this example:</p>
</div>
<div id="ex:two-simple-generator-functions" class="exampleblock">
-<div class="title">Example 66. Two simple generator functions</div>
+<div class="title">Example 67. Two simple generator functions</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -2139,7 +2139,7 @@
keyword, as shown in the next example.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 67. Async as keyword and identifier</div>
+<div class="title">Example 68. Async as keyword and identifier</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -2327,7 +2327,7 @@
Consider the example below.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 68. Type variables with async methods.</div>
+<div class="title">Example 69. Type variables with async methods.</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -2401,7 +2401,7 @@
This is particularly useful in N4JS definition files (.n4jsd) to allow using an existing callback-based API from N4JS code with the more convenient <code>await</code>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 69. Promisifiable</div>
+<div class="title">Example 70. Promisifiable</div>
<div class="content">
<div class="paragraph">
<p>Given a function with an N4JS signature</p>
@@ -2536,7 +2536,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/grammar.html b/spec/grammar.html
index 61df051..133f756 100644
--- a/spec/grammar.html
+++ b/spec/grammar.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1078,7 +1078,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/grammars.html b/spec/grammars.html
index 39a4351..b7a477b 100644
--- a/spec/grammars.html
+++ b/spec/grammars.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -2305,7 +2305,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/index.html b/spec/index.html
index 80d654d..2e6b253 100644
--- a/spec/index.html
+++ b/spec/index.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -841,7 +841,7 @@
<div id="preamble">
<div class="sectionbody">
<div class="paragraph center">
-<p><strong>Last Updated: 2019-08-07</strong></p>
+<p><strong>Last Updated: 2019-08-08</strong></p>
</div>
<div class="paragraph center">
<p><strong>Authors:</strong><br>
@@ -902,7 +902,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/introduction.html b/spec/introduction.html
index 2057270..e9d1fc5 100644
--- a/spec/introduction.html
+++ b/spec/introduction.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1247,7 +1247,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/jsdoc.html b/spec/jsdoc.html
index 5ac5b9d..1a5d8e7 100644
--- a/spec/jsdoc.html
+++ b/spec/jsdoc.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -938,7 +938,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 108. @testee</div>
+<div class="title">Example 109. @testee</div>
<div class="content">
<div class="paragraph">
<p>The target element is to be fully qualified including the module specifier. The module specifier is simply
@@ -967,7 +967,7 @@
the interfaces tested in the base class.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 109. Usage of testeeFromType</div>
+<div class="title">Example 110. Usage of testeeFromType</div>
<div class="content">
<div class="paragraph">
<p>In the following example, the is used. This tag will lead to a test documentation for <code>B.foo</code> and <code>C.foo</code>.</p>
@@ -1037,7 +1037,7 @@
</table>
</div>
<div id="ex:testeetype-and-testeemethod" class="exampleblock">
-<div class="title">Example 110. testeeType and testeeMethod</div>
+<div class="title">Example 111. testeeType and testeeMethod</div>
<div class="content">
<div class="paragraph">
<p>Assume the following testees:</p>
@@ -1120,7 +1120,7 @@
</table>
</div>
<div class="exampleblock">
-<div class="title">Example 111. testeeType and testeeMethod with omitted constraints</div>
+<div class="title">Example 112. testeeType and testeeMethod with omitted constraints</div>
<div class="content">
<div class="paragraph">
<p>Assume testees similar as in <a href="#ex:testeetype-and-testeemethod">testeeType and testeeMethod</a>. Since the semantics of <code>bar</code> is not changed in <code>B</code>, it is probably not necessary to generate the same constraint in the documentation for <code>bar</code> twice (one in the section for class <code>A</code> and another one in the section of class <code>B</code>).
@@ -1219,7 +1219,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/jsobjects.html b/spec/jsobjects.html
index 5b2b071..feb9432 100644
--- a/spec/jsobjects.html
+++ b/spec/jsobjects.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1820,7 +1820,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/jsx.html b/spec/jsx.html
index 3727008..445356c 100644
--- a/spec/jsx.html
+++ b/spec/jsx.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1176,7 +1176,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/n4js_objects.html b/spec/n4js_objects.html
index 19b3e48..58ab426 100644
--- a/spec/n4js_objects.html
+++ b/spec/n4js_objects.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1246,7 +1246,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/names.html b/spec/names.html
index 5c28221..d7980cc 100644
--- a/spec/names.html
+++ b/spec/names.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1815,7 +1815,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/plainjs.html b/spec/plainjs.html
index 6992b31..9ae6f3b 100644
--- a/spec/plainjs.html
+++ b/spec/plainjs.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -1131,7 +1131,7 @@
</div>
</div>
<div id="external-definitions-and-implementations" class="exampleblock">
-<div class="title">Example 104. External Definitions and Their Implementations</div>
+<div class="title">Example 105. External Definitions and Their Implementations</div>
<div class="content">
<div class="paragraph">
<p>If, in addition to standard <code>source</code>, the <code>source-external</code> fragment is provided in <code>Sources</code>, <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>n</mi><mn>4</mn><mi>j</mi><mi>s</mi><mi>d</mi></math> files in the folder tree below source folders
@@ -1152,7 +1152,7 @@
<p>Assume the following non-N4JS module:</p>
</div>
<div id="ex:External_Classes_Example" class="exampleblock">
-<div class="title">Example 105. External Classes</div>
+<div class="title">Example 106. External Classes</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1209,7 +1209,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 106. Structurally-typed external interfaces</div>
+<div class="title">Example 107. Structurally-typed external interfaces</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1370,7 +1370,7 @@
Here, an example of applying a runtime polyfill is detailed.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 107. Object.observe with Polyfill</div>
+<div class="title">Example 108. Object.observe with Polyfill</div>
<div class="content">
<div class="paragraph">
<p>The following snippet demonstrates how to define a polyfill of the built-in class <code>Object</code> to add the new ECMAScript 7 observer functionality.
@@ -1400,7 +1400,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/statements.html b/spec/statements.html
index e1bdf90..56848bc 100644
--- a/spec/statements.html
+++ b/spec/statements.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -948,7 +948,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 93. Variable Statement</div>
+<div class="title">Example 94. Variable Statement</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1558,7 +1558,7 @@
<p>Also see compilation as described in <a href="components.html#_modules">Modules</a>, for semantics see <a href="#import-statement-semantics">Import Statement Semantics</a>.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 94. Import</div>
+<div class="title">Example 95. Import</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -1751,7 +1751,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 95. Imports</div>
+<div class="title">Example 96. Imports</div>
<div class="content">
<div class="paragraph">
<p>Imports cannot be duplicated:</p>
@@ -1986,7 +1986,7 @@
</dl>
</div>
<div class="exampleblock">
-<div class="title">Example 96. Export</div>
+<div class="title">Example 97. Export</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -2029,7 +2029,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
diff --git a/spec/types.html b/spec/types.html
index 1d358a6..ffba1ed 100644
--- a/spec/types.html
+++ b/spec/types.html
@@ -5,7 +5,7 @@
<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=edge"><![endif]-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 1.5.5">
-<meta name="author" content="2019-08-07 15:02:40 CEST">
+<meta name="author" content="2019-08-08 13:15:33 CEST">
<title>N4JS Language Specification</title>
<link rel="stylesheet" href="styles/spec.min.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.6.3/css/font-awesome.min.css">
@@ -47,7 +47,7 @@
<div id="header">
<h1>N4JS Language Specification</h1>
<div class="details">
-<span id="author" class="author">2019-08-07 15:02:40 CEST</span><br>
+<span id="author" class="author">2019-08-08 13:15:33 CEST</span><br>
<span id="revnumber">version 0.9</span>
</div>
<div id="toc" class="toc2">
@@ -3268,27 +3268,129 @@
</div>
</li>
<li>
-<p>Only one class must be contained in the intersection type:</p>
+<p>Only one nominally typed class must be contained in the intersection type:</p>
<div class="openblock">
<div class="content">
-<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close=")" open="("><mrow><mo>∃</mo><mi>C</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>C</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle></mrow></mfenced><mo>→</mo><mo>∄</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>∖</mo><mfenced close="}" open="{"><mi>C</mi></mfenced><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle></math>
+<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mfenced close=")" open="("><mrow><mo>∃</mo><mi>C</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>C</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle><mo>∧</mo><mi>C</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></mrow></mfenced><mo>→</mo><mo>∄</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>∖</mo><mfenced close="}" open="{"><mi>C</mi></mfenced><mi>:</mi><mi>μ</mi><mfenced close=")" open="("><mi>T</mi></mfenced><mo>=</mo><mstyle mathvariant="monospace"><mtext>Class</mtext></mstyle><mo>∧</mo><mi>T</mi><mo>.</mo><mi>i</mi><mi>s</mi><mi>S</mi><mi>t</mi><mi>r</mi><mi>u</mi><mi>c</mi><mi>t</mi><mi>u</mi><mi>r</mi><mi>a</mi><mi>l</mi></math>
</div>
</div>
<div class="paragraph">
-<p>For the time being, only a warning is produced when more than one class is contained in the intersection type .</p>
+<p>A warning is produced when more than one nominal class is contained in the intersection type, since
+only undefined (or null) can be assigned to a type reference of this type.</p>
</div>
</li>
<li>
<p>Non-optional elements:</p>
-</li>
-</ol>
-</div>
<div class="openblock">
<div class="content">
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"><mo>∀</mo><mi>T</mi><mo>∈</mo><mi>I</mi><mo>.</mo><mi>t</mi><mi>y</mi><mi>p</mi><mi>e</mi><mi>R</mi><mi>e</mi><mi>f</mi><mi>s</mi><mo>→</mo><mo>¬</mo><mi>T</mi><mo>.</mo><mi>o</mi><mi>p</mi><mi>t</mi></math>
</div>
</div>
+</li>
+<li>
+<p>If the intersection contains multiple references to the same generic type, a warning is produced if only undefined (or null) can be assigned to a type reference of this type. There are some rare cases in which this does not happen. This is true if for all type arguments one of the following conditions hold:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>a type argument corresponding to a type parameter without def-site variance is a wildcard with an upper bound (use "extends" or no bound) or a type argument not defining an upper bound corresponds to a covariant (out) type parameter, and this constraint (IDE-27) holds for an intersection created from the upper bounds of the type argument (or the lower bound of the type parameter).</p>
+</li>
+<li>
+<p>a type argument is a wildcard with lower bounds (since Object would be a solution)</p>
+</li>
+</ul>
</div>
+</li>
+</ol>
+</div>
+</div>
+</div>
+<div class="paragraph">
+<p>Definition of structural typing attributes see <a href="#Req-ID-78701">[Req-ID-78701]</a>.</p>
+</div>
+<div class="paragraph">
+<p>The combination of intersection types and generics is a bit tricky. The following example demonstrates that:</p>
+</div>
+<div class="exampleblock">
+<div class="title">Example 20. Intersection and generics</div>
+<div class="content">
+<div class="paragraph">
+<p>Given the following types:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>class G<T> {
+ private T: t
+ set(t: T) { this.t = t;}
+ get(): T { return this.t; }
+}
+class C { public y; }
+class D { public x; }
+interface I {}</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>We use the generic with the getter and setter here only to demonstrate co- and contra variance effects.</p>
+</div>
+<div class="paragraph">
+<p>Let</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>let g1: G<C> & G<D>;</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>be a variable. We can only assign undefined to g1, since any other value would not be confirm to the intersection.
+If we for example would assign</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>let gc = new G<C>()
+g1 = gc;</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>we would run into contra-variance problems:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>gc.set(new C());</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This would implicitly also set a <code>C</code> in <code>g1</code>, which would not be compatible with <code>D</code>. This would lead to a problem in the following lines:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>let gd: G<D> = g1;
+let d: D = gd.get();</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This is the typical contra variance problem.</p>
+</div>
+</div>
+</div>
+<div class="paragraph">
+<p>Similar problems arise even with structural types.</p>
+</div>
+<div class="paragraph">
+<p>Note that in theory more warnings could be produced, in particular in combination with
+structural types (and the fact that N4JS classes must explicitly implement even
+structural interfaces). We omit these kind of warnings for two reasons:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>performance</p>
+</li>
+<li>
+<p>anticipated slight changes in semantics (e.g. we may remove the requirement of explicitly implementing structural interfaces)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Since problems caused by not instanceable type references will be detected by programmers before runtime anyway, we do not need to be strict here. They are merely convenience features and they do not affect the correctness of the type system.</p>
</div>
<div class="openblock requirement">
<div class="content">
@@ -3365,7 +3467,7 @@
We also implicitly use this representation in this specification.</p>
</div>
<div class="exampleblock">
-<div class="title">Example 20. Subtyping with intersection type</div>
+<div class="title">Example 21. Subtyping with intersection type</div>
<div class="content">
<div class="paragraph">
<p>Let A, B, and C be defined as in the chapter beginning (<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>C</mi><mo><</mo><mi>:</mi><mi>B</mi><mo><</mo><mi>:</mi><mi>A</mi></math>)</p>
@@ -3924,7 +4026,7 @@
<li>
<p>Overriding of static methods is possible and by using the constructor or classifier type, polymorphism for static methods is possible as well.</p>
<div id="_polymorphism-and-static-methods" class="exampleblock">
-<div class="title">Example 21. Static Polymorphism</div>
+<div class="title">Example 22. Static Polymorphism</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -3948,7 +4050,7 @@
<p>It is even possible to refer to the constructor of an abstract class.
The abstract class itself cannot provide this constructor (it only provides a type..), that is to say only concrete subclasses can provide constructors compatible to the constructor.</p>
<div class="exampleblock">
-<div class="title">Example 22. Constructor of Abstract Class</div>
+<div class="title">Example 23. Constructor of Abstract Class</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -4051,7 +4153,7 @@
code shown in <a href="#ex-constructors-and-prototypes">Constructors and Prototypes</a>.</p>
</div>
<div id="ex-constructors-and-prototypes" class="exampleblock">
-<div class="title">Example 23. Constructors and Prototypes</div>
+<div class="title">Example 24. Constructors and Prototypes</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -4173,7 +4275,7 @@
See <a href="grammar.html#_this-keyword">This Keyword</a> for details.</p>
</div>
<div id="ex:this-keyword-and-type-in-instance-and-static-context" class="exampleblock">
-<div class="title">Example 24. This keyword and type in instance and static context</div>
+<div class="title">Example 25. This keyword and type in instance and static context</div>
<div class="content">
<div class="paragraph">
<p>Note that the following code is not working, because some usages below are
@@ -4273,7 +4375,7 @@
</div>
<div style="page-break-after: always;"></div>
<div class="exampleblock">
-<div class="title">Example 25. This type in function-type-expression</div>
+<div class="title">Example 26. This type in function-type-expression</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -4293,7 +4395,7 @@
In the following example the problem is sketched up. <sup class="footnote">[<a id="_footnoteref_26" class="footnote" href="appendix_c_bibliography.html#_footnote_26" title="View footnote.">26</a>]</sup></p>
</div>
<div class="exampleblock">
-<div class="title">Example 26. Problems with this type and type arguments</div>
+<div class="title">Example 27. Problems with this type and type arguments</div>
<div class="content">
<div class="listingblock">
<div class="content">
@@ -4519,7 +4621,7 @@
</div>
</div>
<div class="exampleblock">
-<div class="title">Example 27. Enumeration List</div>
+<div class="title">Example 28. Enumeration List</div>
<div class="content">
<div class="paragraph">
<p>Due to the common base type <code>N4Enum</code> it is possible to define generics accepting only enumeration, as shown in this example:</p>
@@ -4635,7 +4737,7 @@
</ol>
</div>
<div class="exampleblock">
-<div class="title">Example 28. WebIDL example</div>
+<div class="title">Example 29. WebIDL example</div>
<div class="content">
<div class="listingblock">
<div class="title">Gecko-Engine webIDL XMLHttpRequestResponseType as taken from [<a href="appendix_c_bibliography.html#W3C:Steen:14:XL">W3C:Steen:14:XL</a>]</div>
@@ -4801,7 +4903,7 @@
<div id="footer">
<div id="footer-text">
Version 0.9<br>
-Last updated 2019-08-07 15:02:40 CEST
+Last updated 2019-08-08 13:15:33 CEST
</div>
</div>
<!-- ************* docinfo-footer *************************************************************** -->
