Google Git
Sign in
eclipse / gerrit / objectteams / org.eclipse.objectteams / c633a48739e084c65aa085099612bdcabcee388a / . / plugins / org.eclipse.objectteams.otdt.doc / guide / otjld / def / s1.html
blob: 02440e42cd93db449bffe828af601672f7f8141d [file] [log] [blame]
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" href="../css/ot.css" />
<link rel="stylesheet" type="text/css" href="../css/otjld.css" />
<title>OT/J Language Definition v1.3.1</title>
</head>
<body class="otdt">
<div id="content">
<table class="nav">
<tr>
<td class="back"><a id="top"></a><a href="s0.html" rel="prev">&lt;&lt;&nbsp;&sect;0&nbsp;About this Document</a></td>
<td class="top"><a href="index.html" rel="contents">&uarr;&nbsp;Table of Contents&nbsp;&uarr;</a></td>
<td class="next"><a href="s2.html" rel="next">&sect;2&nbsp;Role Binding&nbsp;&gt;&gt;</a></td>
</tr>
</table>
<div class="chapter" id="s1">
<div class="headl">
<div class="headr">
<h1>&sect;1&nbsp;Teams and Roles</h1>
</div>
</div>
<div id="toc-box">
<ul class="toc-box">
<li><a href="s1.html">&sect;1&nbsp;Teams and Roles</a></li>
<li><a href="#s1.1">&sect;1.1&nbsp;Team classes</a></li>
<li><a href="#s1.2">&sect;1.2&nbsp;Role classes and objects</a></li>
<li><a href="#s1.3">&sect;1.3&nbsp;Acquisition and implicit inheritance of role classes</a></li>
<li><a href="#s1.4">&sect;1.4&nbsp;Name clashes</a></li>
<li><a href="#s1.5">&sect;1.5&nbsp;Team and role nesting</a></li>
</ul>
</div>
<div class="intro">
<h3>Fundamental concepts of Teams</h3>
<div class="line"></div>
<div class="term">Teams and Roles</div>
<div class="termdesc">Classes that are defined with the modifier <code>team</code>
are called team classes, or <strong>teams</strong> for short.<br />
Direct inner classes of a team are called role classes, or <strong>roles</strong>
for short.
</div>
<div class="line"></div>
<div class="term">Role inheritance</div>
<div class="termdesc">Inheritance between teams introduces a special inheritance relationship
between their contained roles. The rules of this <strong>implicit inheritance</strong> are given below (<a href="#s1.3.1"
title="&sect;1.3.1&nbsp;Acquisition and implicit inheritance of role classes"
class="sect">&sect;1.3.1</a>).
</div>
<div class="line"></div>
<div class="term">Externalized role</div>
<div class="termdesc">Roles are generally confined to the context of their
enclosing team instance. Subject to specific restrictions,
a role <em>may</em> be passed outside
its team using the concept of externalized roles (<a href="#s1.2.2" title="&sect;1.2.2&nbsp;Externalized roles" class="sect">&sect;1.2.2</a>).
</div>
<div class="line"></div>
</div>
<div class="sect depth2" id="s1.1">
<h2 class="sect">&sect;1.1&nbsp;Team classes<a class="img" href="s1.html#s1.1"
title="PermaLink to &sect;1.1&nbsp;Team classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#top">&uarr;&nbsp;&sect;1</a></span></h2>
<div class="syntaxlink"><a href="sA.html#sA.1.1" title="&sect;A.1.1&nbsp;ClassDeclaration"
class="syntax">&rarr;&nbsp;Syntax&nbsp;&sect;A.1.1</a></div>
<p>A class declared with the modifier <code>team</code> is a <em>team class</em> (or team for short).
</p>
<div class="listing example frame">
<table class="listing">
<tr class="line odd">
<td class="ln">1</td>
<td><pre><b>public</b> <em><b>team</b> <b>class</b> MyTeamA</em> {</pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre> ...</pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<p>Teams are meant as containers for <em>roles</em>, which are defined in the following
paragraphs.
</p>
<div class="listing example frame">
<table class="listing">
<tr class="line odd">
<td class="ln">1</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre> <b>public</b> <em><b>class</b> MyRole</em></pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre> ...</pre></td>
</tr>
<tr class="line even">
<td class="ln">4</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">5</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<p>Teams introduce a new variant of inheritance for contained role classes
(see <a href="#s1.3.1"
title="&sect;1.3.1&nbsp;Acquisition and implicit inheritance of role classes"
class="sect">&sect;1.3.1</a> below).
Other properties of teams, which are defined in later sections, are:
</p>
<ul>
<li>Team activation (<a href="s5.html" title="&sect;5&nbsp;Team Activation" class="sect">&sect;5</a>)
</li>
<li>Abstractness and instantiation (<a href="s2.html#s2.5" title="&sect;2.5&nbsp;Abstract Roles" class="sect">&sect;2.5</a>)
</li>
<li>Declared lifting in team methods (<a href="s2.html#s2.3.2" title="&sect;2.3.2&nbsp;Declared lifting"
class="sect">&sect;2.3.2</a>)
</li>
<li>Reflective functions defined in <code>org.objectteams.ITeam</code> (<a href="s6.html#s6.1" title="&sect;6.1&nbsp;Reflection" class="sect">&sect;6.1</a>)
</li>
</ul>
<p>Apart from these differences, team classes are regular Java classes with
methods and fields, whose instances are regular Java objects.
</p>
</div>
<div class="sect depth2" id="s1.2">
<h2 class="sect">&sect;1.2&nbsp;Role classes and objects<a class="img" href="s1.html#s1.2"
title="PermaLink to &sect;1.2&nbsp;Role classes and objects"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#top">&uarr;&nbsp;&sect;1</a></span></h2>
<p>Each direct inner class of a team is a role class.
Just like inner classes, each instance of a role class has an implicit reference
to its enclosing team instance. This reference is immutable.
Within the implementation of a role it can be accessed by qualifying the identifier
<code>this</code> with the name of the team class, as in:
</p>
<div class="listing example frame">
<table class="listing">
<tr class="line odd">
<td class="ln">1</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre> <b>public</b> <em><b>class</b> MyRole</em> {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre> <b>public</b> <b>void</b> print() { System.out.println("Team: "+ <em>MyTeamA.this</em>); }</pre></td>
</tr>
<tr class="line even">
<td class="ln">4</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">5</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<p>Creation of role instances is further restricted as defined in
<a href="s2.html#s2.4" title="&sect;2.4&nbsp;Explicit role creation"
class="sect">&sect;2.4</a>.
Teams can also define role interfaces just like role classes.
With respect to role specific properties a role interface is treated like a fully
abstract class.
</p>
<div class="sect depth3" id="s1.2.1">
<h3 class="sect">&sect;1.2.1&nbsp;Modifiers for roles<a class="img" href="s1.html#s1.2.1"
title="PermaLink to &sect;1.2.1&nbsp;Modifiers for roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#s1.2">&uarr;&nbsp;&sect;1.2</a></span></h3>
<p>Member classes of a team cannot be <code>static</code>.
Also the use of access modifiers for roles is restricted and modifiers have different (stronger) semantics than for
regular classes (see below). With respect to accessibility a team acts mainly like a package regarding its roles.
</p>
<div class="subsect depth4" id="s1.2.1.a">
<h4 class="subsect">(a)&nbsp;<span class="title">Role class protection</span><a class="img" href="s1.html#s1.2.1.a"
title="PermaLink to (a)&nbsp;Role class protection"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A role class must have exactly one of the access modifiers <code>public</code>
or <code>protected</code>.<br />
This rule does not affect the class modifiers <code>abstract</code>, <code>final</code> and <code>strictfp</code>.
</p>
</div>
<div class="subsect depth4" id="s1.2.1.b">
<h4 class="subsect">(b)&nbsp;<span class="title">protected role classes</span><a class="img" href="s1.html#s1.2.1.b"
title="PermaLink to (b)&nbsp;protected role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A <code>protected</code> role can only be accessed from within the enclosing
team or any of its sub-teams. The actual border of encapsulation is the
enclosing team <em>instance</em>. The rules for protected roles are given
in <a href="#s1.2.3" title="&sect;1.2.3&nbsp;Protected roles" class="sect">&sect;1.2.3</a> below.
</p>
</div>
<div class="subsect depth4" id="s1.2.1.c">
<h4 class="subsect">(c)&nbsp;<span class="title">public role classes</span><a class="img" href="s1.html#s1.2.1.c"
title="PermaLink to (c)&nbsp;public role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Only <code>public</code> roles can ever be accessed outside their enclosing team.
Accessing a role outside the enclosing team instance is governed by the rules
of <strong>externalized roles</strong>, to be defined next (<a href="#s1.2.2" title="&sect;1.2.2&nbsp;Externalized roles" class="sect">&sect;1.2.2</a>).
</p>
</div>
<div class="subsect depth4" id="s1.2.1.d">
<h4 class="subsect">(d)&nbsp;<span class="title">abstract role classes</span><a class="img" href="s1.html#s1.2.1.d"
title="PermaLink to (d)&nbsp;abstract role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A role class has to be marked <strong>abstract</strong> if any of its methods
is not effective.<br />
The <em>methods of a role class</em> comprise direct methods and
methods acquired by inheritance.
In addition to regular inheritance a role class may acquire methods
also via implicit inheritance (<a href="#s1.3.1"
title="&sect;1.3.1&nbsp;Acquisition and implicit inheritance of role classes"
class="sect">&sect;1.3.1</a>).<br />
A method may become <em>effective</em> by either:
</p>
<ul>
<li>implementation (i.e., a regular method body), or</li>
<li>a callout binding (see <a href="s3.html" title="&sect;3&nbsp;Callout Binding" class="sect">&sect;3</a>).
</li>
</ul>
<p><a href="s2.html#s2.5" title="&sect;2.5&nbsp;Abstract Roles" class="sect">&sect;2.5</a> discusses under which
circumstances abstract roles force the enclosing team to be abstract, too.
</p>
</div>
<div class="subsect depth4" id="s1.2.1.e">
<h4 class="subsect">(e)&nbsp;<span class="title">Role features</span><a class="img" href="s1.html#s1.2.1.e"
title="PermaLink to (e)&nbsp;Role features"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Access modifiers for members of roles have some special interpretation:
</p>
<ol>
<li>A private member is also visible in any implicit sub role
(see implicit inheritance <a href="#s1.3.1.c"
title="&sect;1.3.1.(c)&nbsp;Overriding and implicit inheritance"
class="sect">&sect;1.3.1.(c)</a>).<br />
In contrast to inner classes in Java, private members of a role are not
visible to the enclosing team.
</li>
<li>The default visibility of role members restricts access to the
current class and its sub-classes (explicit and implicit).
</li>
<li><code>protected</code> role members can only be accessed from the enclosing
team or via <a href="s4.html" title="&sect;4&nbsp;Callin Binding" class="sect">callin (&sect;4)</a>.
</li>
<li><code>public</code> role members grant unrestricted access.
</li>
</ol>
<p>Additionally, a role always has access to all the features that its enclosing team has access to.</p>
<p>Only <code>public</code> members can ever be accessed via an <a href="#s1.2.2" title="&sect;1.2.2&nbsp;Externalized roles" class="sect">externalized role (&sect;1.2.2)</a>.
</p>
</div>
<div class="subsect depth4" id="s1.2.1.f">
<h4 class="subsect">(f)&nbsp;<span class="title">Static role methods</span><a class="img" href="s1.html#s1.2.1.f"
title="PermaLink to (f)&nbsp;Static role methods"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>In contrast to inner classes in pure Java, a role class may indeed define static methods. A static role method requires no
role
instance <em>but</em> it still requires a team instance in scope. Static role methods can be called:
</p>
<ul>
<li>from the enclosing team,</li>
<li>via callin (see <a href="s4.html#s4.7"
title="&sect;4.7&nbsp;Callin binding with static methods"
class="sect">&sect;4.7</a>).
</li>
</ul>
<p>Within a static role method the syntax <code>MyTeam.this</code> is available for accessing the enclosing team instance.
</p>
</div>
<div class="subsect depth4" id="s1.2.1.g">
<h4 class="subsect">(g)&nbsp;<span class="title">No static initializers</span><a class="img" href="s1.html#s1.2.1.g"
title="PermaLink to (g)&nbsp;No static initializers"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A static field of a role class must not have a non-constant initialization expression.
Static initialization blocks are already prohibited for inner classes by Java (see <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#262890"
class="ext">JLS &sect;8.1.2</a>).
</p>
<div class="note">
<h5>Note:</h5>
Static initialization generally provides a means for performing initialization code prior to instantiation, i.e., at
class-loading time.
Before any role can be created already two levels of initialization are performed: (1) The (outer most) enclosing team
class performs static initializations when it is loaded. (2) Any enclosing team executes
its constructor when it is instantiated. It should be possible to allocate any early initialization to either of these
two phases instead of using static role initializers.
</div>
</div>
</div>
<div class="sect depth3" id="s1.2.2">
<h3 class="sect">&sect;1.2.2&nbsp;Externalized roles<a class="img" href="s1.html#s1.2.2"
title="PermaLink to &sect;1.2.2&nbsp;Externalized roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#s1.2">&uarr;&nbsp;&sect;1.2</a></span></h3>
<div class="syntaxlink"><a href="sA.html#sA.9.2" title="&sect;A.9.2&nbsp;ActualTypeArgument"
class="syntax">&rarr;&nbsp;Syntax&nbsp;&sect;A.9.2</a></div>
<p>Normally, a team encapsulates its role against unwanted access from the outside.
If roles are visible outside their enclosing team instance we speak of
<strong>externalized roles</strong>.
</p>
<p>Externalized roles are subject to specific typing rules in order to ensure,
that role instances from different team instances cannot be mixed in
inconsistent ways. In the presence of implicit inheritance
(<a href="#s1.3.1"
title="&sect;1.3.1&nbsp;Acquisition and implicit inheritance of role classes"
class="sect">&sect;1.3.1</a>) inconsistencies could otherwise occur, which lead
to typing errors that could only be detected at run-time.
Externalized roles use the theory of
"virtual classes" <a href="#fn1-virtual-classes" class="int">[1]</a>,
or more specifically
"family polymorphism" <a href="#fn2-family-polymorphism" class="int">[2]</a>,
in order to achieve the desired type safety.
These theories use special forms of <em>dependent types</em>.
Externalized roles have <em>types that depend on a team instance</em>.
</p>
<p><a href="#s1.2.3" title="&sect;1.2.3&nbsp;Protected roles" class="sect">&sect;1.2.3</a> deduces even stronger forms of encapsulation
from the rules about externalized roles.
</p>
<div class="subsect depth4" id="s1.2.2.a">
<h4 class="subsect">(a)&nbsp;<span class="title">Visibility</span><a class="img" href="s1.html#s1.2.2.a" title="PermaLink to (a)&nbsp;Visibility"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Only instances of a <code>public</code> role class can ever be externalized.
</p>
</div>
<div class="subsect depth4" id="s1.2.2.b">
<h4 class="subsect">(b)&nbsp;<span class="title">Declaration with anchored type</span><a class="img" href="s1.html#s1.2.2.b"
title="PermaLink to (b)&nbsp;Declaration with anchored type"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Outside a team role types are legal only if denoted relative
to an existing team instance (further on called "anchored types").
The syntax is:
</p>
<div class="listing plain"><pre><em>final</em> MyTeam myTeam = <i>expression</i>;
<em>RoleClass&lt;@myTeam&gt;</em> role = <i>expression</i>;</pre></div>
<p>The syntax <code>Type&lt;@anchor&gt;</code> is a special case of a parameterized type, more specifically a <a href="s9.html" title="&sect;9&nbsp;Value Dependent Classes" class="sect">value dependent type (&sect;9)</a>.
The type argument (i.e., the expression after the at-sign) can be a simple name or a path. It must refer to an instance
of a team class.
The role type is said to be <em>anchored</em> to this team instance.<br />
The type-part of this syntax (in front of the angle brackets) must be the simple name of a role type directly contained
in the given team (including roles that are acquired by implicit inheritance).<br /></p>
<div class="note">
<h5>Note:</h5>
Previous versions of the OTJLD used a different syntax for anchored types, where the role type was prefixed with the anchor
expression, separated by a dot (<code>anchor.Type</code>,
see <a href="sA.html#sA.6.3" title="&sect;A.6.3&nbsp;AnchoredType" class="sect">&sect;A.6.3</a>). A compiler may still support that path syntax but it should be flagged as being deprecated.
</div>
</div>
<div class="subsect depth4" id="s1.2.2.c">
<h4 class="subsect">(c)&nbsp;<span class="title">Immutable anchor</span><a class="img" href="s1.html#s1.2.2.c"
title="PermaLink to (c)&nbsp;Immutable anchor"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Anchoring the type of an externalized role to a team instance
requires the team to be referenced by a variable which
is marked <code>final</code> (i.e., immutable).
The type anchor can be a path <code>v.f1.f2...</code> where
<code>v</code> is any final variable and <code>f1</code> ...
are final fields.
</p>
</div>
<div class="subsect depth4" id="s1.2.2.d">
<h4 class="subsect">(d)&nbsp;<span class="title">Implicit type anchors</span><a class="img" href="s1.html#s1.2.2.d"
title="PermaLink to (d)&nbsp;Implicit type anchors"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>The current team instance can be used as a default anchor
for role types:
</p>
<ol>
<li>In non-static team level methods role types are by default interpreted as anchored to <code>this</code> (referring to the team instance). I.e., the following two declarations express the same:
<div class="listing plain"><pre><b>public</b> RoleX getRoleX (RoleY r) { <i> stmts </i> }
<b>public</b> RoleX&lt;@<em>this</em>&gt; getRoleX (RoleY&lt;@<em>this</em>&gt; r) { <i> stmts </i> }</pre></div>
</li>
<li>
In analogy, <em>role methods</em> use the enclosing team instance as the
default anchor for any role types.
</li>
</ol>
<p>Note, that <code>this</code> and <code><em>Outer</em>.this</code> are always
<code>final</code>.<br />
The compiler uses the pseudo identifier <strong><code>tthis</code></strong> to denote
such implicit type anchors in error messages.
</p>
</div>
<div class="subsect depth4" id="s1.2.2.e">
<h4 class="subsect">(e)&nbsp;<span class="title">Conformance</span><a class="img" href="s1.html#s1.2.2.e" title="PermaLink to (e)&nbsp;Conformance"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Conformance between
two types <code>RoleX&lt;@teamA&gt;</code> and <code>RoleY&lt;@teamB&gt;</code>
not only requires the role types to be compatible, but also
the team instances to be provably <em>the same object</em>.
The compiler must be able to statically analyze anchor identity.
</p>
</div>
<div class="subsect depth4" id="s1.2.2.f">
<h4 class="subsect">(f)&nbsp;<span class="title">Substitutions for type anchors</span><a class="img" href="s1.html#s1.2.2.f"
title="PermaLink to (f)&nbsp;Substitutions for type anchors"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Only two substitutions are considered for determining
team identity:
</p>
<ol>
<li>
For type checking the application of team methods,
<code>this</code> is <strong>substituted</strong> by the actual call target.
For role methods a reference of the form <code><em>Outer</em>.this</code>
is substituted by the enclosing instance of the call target.
</li>
<li>Assignments from a <code>final</code> identifier
to another <code>final</code> identifier are transitively
followed, i.e., if <code>t1, t2</code> are final,
after an assignment <code>t1=t2</code>
the types <code>R&lt;@t1&gt;</code> and <code>R&lt;@t2&gt;</code> are considered
identical. Otherwise <code>R&lt;@t1&gt;</code> and <code>R&lt;@t2&gt;</code>
are incommensurable.<br />
Attaching an actual parameter to a formal parameter in a
method call is also considered as an assignment with respect to
this rule.
</li>
</ol>
</div>
<div class="subsect depth4" id="s1.2.2.g">
<h4 class="subsect">(g)&nbsp;<span class="title">Legal contexts</span><a class="img" href="s1.html#s1.2.2.g"
title="PermaLink to (g)&nbsp;Legal contexts"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Anchored types for externalized roles may be used in the
following contexts:
</p>
<ol>
<li>Declaration of an attribute</li>
<li>Declaration of a local variable</li>
<li>Declaration of a parameter or result type
of a method or constructor
</li>
<li>In the <code>playedBy</code> clause of a role class
(see <a href="s2.html#s2.1" title="&sect;2.1&nbsp;playedBy relation" class="sect">&sect;2.1</a>).
</li>
</ol>
<p>It is not legal to inherit from an anchored type, since
this would require membership of the referenced team instance,
which can only be achieved by class nesting.
</p>
<div class="note">
<h5>Note:</h5>
Item 4.
&mdash; within the given restriction &mdash; admits the case where
the same class is a role of one team and the base class for
the role of another team. Another form of nesting is
defined in <a href="#s1.5" title="&sect;1.5&nbsp;Team and role nesting" class="sect">&sect;1.5</a>.
</div>
</div>
<div class="subsect depth4" id="s1.2.2.h">
<h4 class="subsect">(h)&nbsp;<span class="title">Externalized creation</span><a class="img" href="s1.html#s1.2.2.h"
title="PermaLink to (h)&nbsp;Externalized creation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A role can be created as externalized using either of these equivalent forms:</p>
<div class="listing plain"><pre>outer.<b>new</b> Role()
<b>new</b> Role&lt;@outer&gt;()</pre></div>
<p>This requires the enclosing instance <code>outer</code> to be
declared <code>final</code>. The expression has the
type <code>Role&lt;@outer&gt;</code> following the rules of
externalized roles.<br />
The type <code>Role</code> in this expression must be a simple
(unqualified) name.
</p>
</div>
<div class="subsect depth4" id="s1.2.2.i">
<h4 class="subsect">(i)&nbsp;<span class="title">No import</span><a class="img" href="s1.html#s1.2.2.i" title="PermaLink to (i)&nbsp;No import"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>It is neither useful nor legal to import a role type.<br /></p>
<div class="note">
<h5>Rationale:</h5>
Importing a type allows to use the unqualified name in situations that would otherwise require to use the fully qualified
name,
i.e., the type prefixed with its containing package and enclosing class. Roles, however are contained in a team <i>instance</i>.
Outside their team, role types can only be accessed using an anchored type which uses a team instance to qualify the
role type.
Relative to this team anchor, roles are <i>always</i> denoted using their simple name, which makes importing roles useless.
</div>
<p>A static import for a constant declared in a role is, however, legal.
</p>
</div>
<h5 class="listing">Example code (Externalized Roles):</h5>
<div class="listing example frame" id="l1.2.2-1">
<table class="listing">
<tr class="line odd">
<td class="ln">1</td>
<td><pre><b>team</b> <b>class</b> FlightBonus <b>extends</b> Bonus {</pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre> <b>public</b> <b>class</b> Subscriber {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre> <b>void</b> clearCredits() { ... }</pre></td>
</tr>
<tr class="line even">
<td class="ln">4</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">5</td>
<td><pre> <b>void</b> unsubscribe(Subscriber subscr) { ... }</pre></td>
</tr>
<tr class="line even">
<td class="ln">6</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<div class="listing example frame" id="l1.2.2-2">
<table class="listing">
<tr class="line odd">
<td class="ln">7</td>
<td><pre><b>class</b> ClearAction <b>extends</b> Action {</pre></td>
</tr>
<tr class="line even">
<td class="ln">8</td>
<td><pre> <em>final</em> FlightBonus context;</pre></td>
</tr>
<tr class="line odd">
<td class="ln">9</td>
<td><pre> <em>Subscriber&lt;@context&gt;</em> subscriber;</pre></td>
</tr>
<tr class="line even">
<td class="ln">10</td>
<td><pre> ClearAction (<em>final</em> FlightBonus bonus, <em>Subscriber&lt;@bonus&gt;</em> subscr) {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">11</td>
<td><pre> context = bonus; <span class="comment">// unique assignment to 'context'</span></pre></td>
</tr>
<tr class="line even">
<td class="ln">12</td>
<td><pre> subscriber = subscr;</pre></td>
</tr>
<tr class="line odd">
<td class="ln">13</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">14</td>
<td><pre> <b>void</b> actionPerformed () {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">15</td>
<td><pre> subscriber.clearCredits();</pre></td>
</tr>
<tr class="line even">
<td class="ln">16</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">17</td>
<td><pre> <b>protected</b> <b>void</b> finalize () {</pre></td>
</tr>
<tr class="line even">
<td class="ln">18</td>
<td><pre> context.unsubscribe(subscriber);</pre></td>
</tr>
<tr class="line odd">
<td class="ln">19</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">20</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<div class="codecomment">
<h5>Effects:</h5>
<ul>
<li>Lines 1-6 show a terse extract of a published example
<a href="http://www.objectteams.org/publications/index.html#NODe02" class="ext">[NODe02]</a>. Here passengers can be subscribers in a flight bonus program.
</li>
<li>Lines 7-20 show a sub-class of <code>Action</code> which is
used to associate the action of resetting a subscriber's credits
to a button or similar element in an application's GUI.
</li>
<li>Attribute <code>context</code> (line 8) and parameter
<code>bonus</code> (line 10) serve as anchor for the type of
externalized roles.
</li>
<li>Attribute <code>subscriber</code> (line 9) and parameter
<code>subscr</code> (line 10) store a Subscriber role outside the
FlightBonus team.
</li>
<li>In order to type-check the assignment in line 12, the compiler
has to ensure that the types of LHS and RHS are anchored to
the same team instance. This can be verified by checking that
both anchors are indeed <code>final</code> and prior to the
role assignment a team assignment has taken place (line 11).<br /><span class="underline">Note,</span> that the Java rules for <strong>definite assignments</strong> to
final variables ensure that exactly one assignment to a variable occurs
prior to its use as type anchor. No further checks are needed.
</li>
<li>It is now legal to store this role reference and use it at
some later point in time, e.g., for invoking method
<code>clearCredits</code> (line 15).
This method call is also an example for implicit team activation
(<a href="s5.html#s5.3.b"
title="&sect;5.3.(b)&nbsp;Methods of externalized roles"
class="sect">&sect;5.3.(b)</a>).
</li>
<li>Line 18 demonstrates how an externalized role can be
passed to a team level method. The signature of <code>unsubscribe</code>
is for this call expanded to
<div class="indent">
void unsubscribe(Subscriber&lt;@context&gt; subscr)
</div>
(by substituting the call target <code>context</code> for
<code>this</code>). This proves identical types for actual and
formal parameters.
</li>
</ul>
</div>
</div>
<div class="sect depth3" id="s1.2.3">
<h3 class="sect">&sect;1.2.3&nbsp;Protected roles<a class="img" href="s1.html#s1.2.3"
title="PermaLink to &sect;1.2.3&nbsp;Protected roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#s1.2">&uarr;&nbsp;&sect;1.2</a></span></h3>
<p>Roles can only be <code>public</code> or <code>protected</code>.
A <code>protected</code> role is encapsulated
by its enclosing team instance. This is enforced by these rules:
</p>
<div class="subsect depth4" id="s1.2.3.a">
<h4 class="subsect">(a)&nbsp;<span class="title">Importing role classes</span><a class="img" href="s1.html#s1.2.3.a"
title="PermaLink to (a)&nbsp;Importing role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p><i>This rule is superseded by <a href="#s1.2.2.i" title="&sect;1.2.2.(i)&nbsp;No import" class="sect">&sect;1.2.2.(i)</a></i></p>
</div>
<div class="subsect depth4" id="s1.2.3.b">
<h4 class="subsect">(b)&nbsp;<span class="title">Qualified role types</span><a class="img" href="s1.html#s1.2.3.b"
title="PermaLink to (b)&nbsp;Qualified role types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>The name of a <code>protected</code> role class may never be used qualified, neither
prefixed by its <em>enclosing type</em> nor parameterized by a <em>variable as type anchor</em> (cf. <a href="#s1.2.2.a" title="&sect;1.2.2.(a)&nbsp;Visibility" class="sect">&sect;1.2.2.(a)</a>).
</p>
</div>
<div class="subsect depth4" id="s1.2.3.c">
<h4 class="subsect">(c)&nbsp;<span class="title">Mixing qualified and unqualified types</span><a class="img" href="s1.html#s1.2.3.c"
title="PermaLink to (c)&nbsp;Mixing qualified and unqualified types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>An externalized role type is never compatible to an unqualified role type,
except for the substitutions in <a href="#s1.2.2.f"
title="&sect;1.2.2.(f)&nbsp;Substitutions for type anchors"
class="sect">&sect;1.2.2.(f)</a>, where
an explicit anchor can be matched with the implicit anchor <code>this</code>.
</p>
</div>
<p>Rules (a) and (b) ensure that the name of a protected role class cannot be used
outside the lexical scope of its enclosing team. Rule (c) ensures that team methods
containing unqualified role types in their signature cannot be invoked on a team other
than the current team. Accordingly, for role methods the team context must be the
enclosing team instance.
</p>
<div class="subsect depth4" id="s1.2.3.d">
<h4 class="subsect">(d)&nbsp;<span class="title">Levels of encapsulation</span><a class="img" href="s1.html#s1.2.3.d"
title="PermaLink to (d)&nbsp;Levels of encapsulation"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Since protected role types can not be used for externalization, instances of these types are already quite effectively encapsulated
by their enclosing team.
Based on this concept, encapsulation for protected roles can be made even stricter by the rules of <em>role confinement</em>.
On the contrary, even protected roles can be externalized as <em>opaque roles</em> which still expose (almost) no information.
Confinement and opaque roles are subject of <a href="s7.html" title="&sect;7&nbsp;Role Encapsulation" class="sect">&sect;7</a>.
</p>
</div>
</div>
<div class="sect depth3" id="s1.2.4">
<h3 class="sect">&sect;1.2.4&nbsp;Type tests and casts<a class="img" href="s1.html#s1.2.4"
title="PermaLink to &sect;1.2.4&nbsp;Type tests and casts"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#s1.2">&uarr;&nbsp;&sect;1.2</a></span></h3>
<p>In accordance with <a href="#s1.2.2.e" title="&sect;1.2.2.(e)&nbsp;Conformance" class="sect">&sect;1.2.2.(e)</a>, in OT/J
the <code>instanceof</code> operator and type casts have extended semantics for roles.
</p>
<div class="subsect depth4" id="s1.2.4.a">
<h4 class="subsect">(a)&nbsp;<span class="title">instanceof</span><a class="img" href="s1.html#s1.2.4.a" title="PermaLink to (a)&nbsp;instanceof"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>For role types the <code>instanceof</code> operator yields true only if
both components of the type match: the dynamic role type must be compatible
to the given static type, and also type anchors must be the same instance.
</p>
</div>
<div class="subsect depth4" id="s1.2.4.b">
<h4 class="subsect">(b)&nbsp;<span class="title">Casting</span><a class="img" href="s1.html#s1.2.4.b" title="PermaLink to (b)&nbsp;Casting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Casts may also fail if the casted expression is anchored to a different
team instance than the cast type. Such failure is signaled by a
<code>org.objectteams.RoleCastException</code>.
</p>
</div>
<div class="subsect depth4" id="s1.2.4.c">
<h4 class="subsect">(c)&nbsp;<span class="title">Class literal</span><a class="img" href="s1.html#s1.2.4.c"
title="PermaLink to (c)&nbsp;Class literal"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A class literal of form <code>R.class</code> is dynamically bound to the class <code>R</code>
visible in the current instance context. Using a class literal for a role outside its
enclosing team instance (see <a href="#s1.2.2" title="&sect;1.2.2&nbsp;Externalized roles" class="sect">&sect;1.2.2</a>) requires the following syntax:
</p>
<div class="listing plain"><pre>RoleClass<em>&lt;@teamAnchor&gt;</em><strong>.class</strong></pre></div>
</div>
</div>
<div class="sect depth3" id="s1.2.5">
<h3 class="sect">&sect;1.2.5&nbsp;File structure<a class="img" href="s1.html#s1.2.5"
title="PermaLink to &sect;1.2.5&nbsp;File structure"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#s1.2">&uarr;&nbsp;&sect;1.2</a></span></h3>
<p>Just like regular inner classes, role classes may be inlined in the
source code of the enclosing team. As an alternative style it is possible
to store role classes in separate <strong>role files</strong> according to the following rules:
</p>
<div class="subsect depth4" id="s1.2.5.a">
<h4 class="subsect">(a)&nbsp;<span class="title">Role directory</span><a class="img" href="s1.html#s1.2.5.a"
title="PermaLink to (a)&nbsp;Role directory"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>In the directory of the team class a new directory is created
which has the same name as the team without the <tt>.java</tt> suffix.
</p>
</div>
<div class="subsect depth4" id="s1.2.5.b">
<h4 class="subsect">(b)&nbsp;<span class="title">Role files</span><a class="img" href="s1.html#s1.2.5.b" title="PermaLink to (b)&nbsp;Role files"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Role classes are stored in this directory (a). The file names are
derived from the role class name extended by <tt>.java</tt>.<br />
A role file must contain exactly one top-level type.
</p>
</div>
<div class="subsect depth4" id="s1.2.5.c">
<h4 class="subsect">(c)&nbsp;<span class="title">package statement</span><a class="img" href="s1.html#s1.2.5.c"
title="PermaLink to (c)&nbsp;package statement"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A role class in a role file declares as its package the fully qualified
name of the enclosing team class. The package statement of a role file
must use the <code>team</code> modifier as its first token.
</p>
</div>
<div class="subsect depth4" id="s1.2.5.d">
<h4 class="subsect">(d)&nbsp;<span class="title">Reference to role file</span><a class="img" href="s1.html#s1.2.5.d"
title="PermaLink to (d)&nbsp;Reference to role file"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A team should mention in its javadoc comment each role class which
is stored externally using a <tt>@role</tt> tag.
</p>
</div>
<div class="subsect depth4" id="s1.2.5.e">
<h4 class="subsect">(e)&nbsp;<span class="title">Legal types in role files</span><a class="img" href="s1.html#s1.2.5.e"
title="PermaLink to (e)&nbsp;Legal types in role files"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>The type in a role file must not be an <code>enum</code>.
</p>
</div>
<div class="subsect depth4" id="s1.2.5.f">
<h4 class="subsect">(f)&nbsp;<span class="title">Imports in role files</span><a class="img" href="s1.html#s1.2.5.f"
title="PermaLink to (f)&nbsp;Imports in role files"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A role file may have imports of its own.
Within the role definition these imports are visible <em>in addition</em> to all imports of the enclosing team.
Only <code>base</code> imports (see <a href="s2.html#s2.1.2.d" title="&sect;2.1.2.(d)&nbsp;Base imports"
class="sect">&sect;2.1.2.(d)</a>)
<em>must</em> be defined in the team.
</p>
</div>
<p>Semantically, there is no difference between inlined role classes and those
stored in separate role files.
</p>
<div class="note">
<h5>Note:</h5>
Current Java compilers disallow a type to have the same fully qualified
name as a package. However, the JLS does not seem to make a statement in this respect.
In OT/J, a package and a type are interpreted as being the same team, if both have the
same fully qualified name and both have the <code>team</code> modifier.
</div>
<h5 class="listing">Role file example:</h5>
<div class="listing example frame" id="l1.2.5-1">
<table class="listing">
<tr class="lhead">
<td colspan="2">in file <code>org/objectteams/examples/MyTeamA.java</code> :
</td>
</tr>
<tr class="line odd">
<td class="ln">1</td>
<td><pre><b>package</b> org.objectteams.examples;</pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre><span class="comment">/**</span></pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre> <span class="comment">* @author Stephan Herrmann</span></pre></td>
</tr>
<tr class="line even">
<td class="ln">4</td>
<td><pre> <span class="comment">* @date 20.02.2007</span></pre></td>
</tr>
<tr class="line odd">
<td class="ln">5</td>
<td><pre> <span class="comment">* @file MyTeamA.java</span></pre></td>
</tr>
<tr class="line even">
<td class="ln">6</td>
<td><pre> <span class="comment">* <em>@role MyRole</em></span></pre></td>
</tr>
<tr class="line odd">
<td class="ln">7</td>
<td><pre> <span class="comment">*/</span></pre></td>
</tr>
<tr class="line even">
<td class="ln">8</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">9</td>
<td><pre> ...</pre></td>
</tr>
<tr class="line even">
<td class="ln">10</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<div class="listing example frame" id="l1.2.5-2">
<table class="listing">
<tr class="lhead">
<td colspan="2">in file <code>org/objectteams/examples<strong class="blue">/MyTeamA/MyRole.java</strong></code>:
</td>
</tr>
<tr class="line odd">
<td class="ln">1</td>
<td><pre><em><b>team</b> <b>package</b> org.objectteams.examples.MyTeamA;</em></pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre><b>public</b> <b>class</b> MyRole {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre> ...</pre></td>
</tr>
<tr class="line even">
<td class="ln">4</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
</div>
</div>
<div class="sect depth2" id="s1.3">
<h2 class="sect">&sect;1.3&nbsp;Acquisition and implicit inheritance of role classes<a class="img" href="s1.html#s1.3"
title="PermaLink to &sect;1.3&nbsp;Acquisition and implicit inheritance of role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#top">&uarr;&nbsp;&sect;1</a></span></h2>
<p> Every team class implicitly implements the predefined interface <code>org.objectteams.ITeam</code>.
If a team class has no explicit <code>extends</code> clause it implicitly extends <code>org.objectteams.Team</code>,
thus providing implementations for the methods in <code>org.objectteams.ITeam</code>.
If a team class extends a non-team class, the compiler implicitly adds implementations for all methods declared
in <code>org.objectteams.ITeam</code> to the team class.
Any subclass of a team (including <code>org.objectteams.Team</code>) must again be a team.
Interface implementation is not affected by this rule.
</p>
<p>Infrastructure provided via interface <code>org.objectteams.ITeam</code> is presented in <a href="s6.html" title="&sect;6&nbsp;Object Teams API" class="sect">&sect;6</a>.
</p>
<div class="sect depth3" id="s1.3.1">
<h3 class="sect">&sect;1.3.1&nbsp;Acquisition and implicit inheritance of role classes<a class="img" href="s1.html#s1.3.1"
title="PermaLink to &sect;1.3.1&nbsp;Acquisition and implicit inheritance of role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#s1.3">&uarr;&nbsp;&sect;1.3</a></span></h3>
<p>A team acquires all roles from its super-team. This relation is
similar to inheritance of inner classes, but with a few decisive
differences as defined next. Two implementation options are mentioned <a href="#aux1.1" class="int">below</a>,
which can be used to realize the special semantics of role
acquisition (virtual classes and copy inheritance).
</p>
<h5 class="listing">Implicit role inheritance</h5>
<div class="listing example frame" id="l1.3.1-1">
<table class="listing">
<tr class="line odd">
<td class="ln">1</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> S {</pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre> <b>protected</b> <b>class</b> R0 {...}</pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre> <b>protected</b> <b>class</b> R1 <em><b>extends</b> R0</em> {</pre></td>
</tr>
<tr class="line even">
<td class="ln">4</td>
<td><pre> <b>boolean</b> ok;</pre></td>
</tr>
<tr class="line odd">
<td class="ln">5</td>
<td><pre> R2 m() {...}</pre></td>
</tr>
<tr class="line even">
<td class="ln">6</td>
<td><pre> <b>void</b> n(<em>R2</em> r) {...}</pre></td>
</tr>
<tr class="line odd">
<td class="ln">7</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">8</td>
<td><pre> <b>protected</b> <b>class</b> R2 {...}</pre></td>
</tr>
<tr class="line odd">
<td class="ln">9</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<div class="listing example frame" id="l1.3.1-2">
<table class="listing">
<tr class="line odd">
<td class="ln">10</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> T <em><b>extends</b> S</em> {</pre></td>
</tr>
<tr class="line even">
<td class="ln">11</td>
<td><pre> @Override <b>protected</b> <em><b>class</b> R1</em> {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">12</td>
<td><pre> <strong>R2</strong> m() {</pre></td>
</tr>
<tr class="line even">
<td class="ln">13</td>
<td><pre> if(<em>ok</em>) { <b>return</b> <em>tsuper</em>.m(); }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">14</td>
<td><pre> <b>else</b> { <b>return</b> null; }</pre></td>
</tr>
<tr class="line even">
<td class="ln">15</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">16</td>
<td><pre> <b>void</b> doIt() {</pre></td>
</tr>
<tr class="line even">
<td class="ln">17</td>
<td><pre> n(m());</pre></td>
</tr>
<tr class="line odd">
<td class="ln">18</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">19</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">20</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<div class="subsect depth4" id="s1.3.1.a">
<h4 class="subsect">(a)&nbsp;<span class="title">Role class acquisition</span><a class="img" href="s1.html#s1.3.1.a"
title="PermaLink to (a)&nbsp;Role class acquisition"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A team <code>T</code> which extends a super-team <code>S</code>
has one role class <code>T.R</code> corresponding to each role <code>S.R</code>
of the super-team.
The new type <code>T.R</code>&nbsp;<strong>overrides</strong>&nbsp;<code>R</code> for the
context of <code>T</code> and its roles.
Acquisition of role classes can either be direct (see (b) below), or
it may involve overriding and implicit inheritance ((c) below).
</p>
<div class="codecomment">In the above example (<a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a>) the team <code>S</code> operates
on types <code>S.R0</code>, <code>S.R1</code> and <code>S.R2</code>,
while <code>T</code> operates on types <code>T.R0</code>, <code>T.R1</code>
and <code>T.R2</code>.<br /><em>(Type references like "<code>S.R0</code>" are actually illegal in source code
(<a href="#s1.2.3.b" title="&sect;1.2.3.(b)&nbsp;Qualified role types"
class="sect">&sect;1.2.3.(b)</a>). Here they are used for explanatory purposes only)</em></div>
</div>
<div class="subsect depth4" id="s1.3.1.b">
<h4 class="subsect">(b)&nbsp;<span class="title">Direct role acquisition</span><a class="img" href="s1.html#s1.3.1.b"
title="PermaLink to (b)&nbsp;Direct role acquisition"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Within a sub-team <code>T</code> each role <code>S.R</code> of its
super-team <code>S</code> is available by the simple name <code>R</code>
without further declaration.
</p>
<div class="codecomment">The role <code>R2</code> in <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a> can be used in the sub-team
<code>T</code> (line 12), because this role type is defined in the super class of the enclosing team.
</div>
</div>
<div class="subsect depth4" id="s1.3.1.c">
<h4 class="subsect">(c)&nbsp;<span class="title">Overriding and implicit inheritance</span><a class="img" href="s1.html#s1.3.1.c"
title="PermaLink to (c)&nbsp;Overriding and implicit inheritance"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>If a team contains a role class definition by the same name as
a role defined in its super-team,
the new role class overrides the corresponding role from the super-team
and <strong>implicitly inherits</strong> all of its features.
Such relation is established only by name correspondence.
</p>
<p>A role that overrides an inherited role should be marked with an <code>@Override</code> annotation.
A compiler should optionally flag a missing <code>@Override</code> annotation with a warning.
Conversely, it is an error if a role is marked with an <code>@Override</code> annotation but does not actually
override an inherited role.
</p>
<p>It is an error to override a role class with an interface or vice versa. A final role cannot be overridden.<br />
Unlike regular inheritance, <strong>constructors</strong> are also inherited
along implicit inheritance, and can be overridden just like normal methods.
</p>
<div class="codecomment">
In <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a><code> R1</code> in <code>T</code> implicitly inherits all features of
<code>R1</code> in <code>S</code>. This is, because its enclosing team
<code>T</code> extends the team <code>S</code> (line 10) and the role
definition uses the same name <code>R1</code> (line 11).
Hence the attribute <code><strong>ok</strong></code> is available in the method
<code>m()</code> in <code>T.R1</code> (line 13). <code>T.R1</code> also overrides <code>S.R1</code>
which is marked by the <code>@Override</code> annotation in line 11.
</div>
</div>
<div class="subsect depth4" id="s1.3.1.d">
<h4 class="subsect">(d)&nbsp;<span class="title">Lack of subtyping</span><a class="img" href="s1.html#s1.3.1.d"
title="PermaLink to (d)&nbsp;Lack of subtyping"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Direct acquisition of roles from a super-team and implicit inheritance
do not establish a <strong>subtype</strong> relation.
A role of a given team is never conform (i.e., substitutable)
to any role of any <em>other</em> team.
<code>S.R</code> and <code>T.R</code> are always incommensurable.<br /><span class="underline">Note,</span> that this rule is a direct consequence of <a href="#s1.2.2.e" title="&sect;1.2.2.(e)&nbsp;Conformance" class="sect">&sect;1.2.2.(e)</a>.
</p>
</div>
<div class="subsect depth4" id="s1.3.1.e">
<h4 class="subsect">(e)&nbsp;<span class="title">Dynamic binding of types</span><a class="img" href="s1.html#s1.3.1.e"
title="PermaLink to (e)&nbsp;Dynamic binding of types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Overriding an acquired role by a new role class has the following
implication: If an expression or declaration, which is evaluated on behalf of
an instance of team <code>T</code> or one of its contained roles,
refers to a role <code>R</code>, <code>R</code> will always
resolve to <code>T.R</code> even if <code>R</code> was introduced in
a super-team of <code>T</code> and even if the specific line of code
was inherited from a super-team or one of its roles.
Only the dynamic type of the enclosing team-instance is used to determine
the correct role class (see below for an example).
</p>
<p>A special case of dynamically binding role types relates to so-called class literals
(see <a href="http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#251530"
class="ext">JLS &sect;15.8.2</a>).
Role class literals are covered in <a href="s6.html#s6.1.c" title="&sect;6.1.(c)&nbsp;Class literals for roles"
class="sect">&sect;6.1.(c)</a>.
</p>
<p>The above is strictly needed only for cases involving implicit inheritance.
It may, however, help intuition, to also consider the directly acquired
role <code>T.R</code> in (b) to override the given role <code>S.R</code>.
</p>
<div class="codecomment">
In line 17 of <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a> the implicitly inherited method <code>n</code> is called
with the result of an invocation of <code>m</code>. Although
<code>n</code> was defined in <code>S</code> (thus with argument type
<code>S.R2, see line 6</code>) in the context of <code>T</code> it
expects an argument of <code>T.R2</code>. This is correctly provided by
the invocation of <code>m</code> in the context of <code>T</code>.
</div>
</div>
<div class="subsect depth4" id="s1.3.1.f">
<h4 class="subsect">(f)&nbsp;<span class="title">tsuper</span><a class="img" href="s1.html#s1.3.1.f" title="PermaLink to (f)&nbsp;tsuper"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<div class="syntaxlink"><a href="sA.html#sA.5.4" title="&sect;A.5.4&nbsp;TSuperCall" class="syntax">&rarr;&nbsp;Syntax&nbsp;&sect;A.5.4</a></div>
<p>Super calls along implicit inheritance use the new keyword
<strong>tsuper</strong>. While <code>super</code> is still available
along regular inheritance, a call <code>tsuper.m()</code>
selects the version of <code>m</code> of the corresponding role
acquired from the super-team.
</p>
<p>See <a href="s2.html#s2.4.2"
title="&sect;2.4.2&nbsp;Role creation via a regular constructor"
class="sect">&sect;2.4.2</a> for <code>tsuper</code>
in the context of role constructors.
</p>
<p><code>tsuper</code> can only be used to invoke a corresponding
version of the enclosing method or constructor, i.e., an expression
<code>tsuper.m()</code> may only occur within the method <code>m</code>
with both methods having the same signature
(see <a href="s2.html#s2.3.2.b"
title="&sect;2.3.2.(b)&nbsp;Super in the context of declared lifting"
class="sect">&sect;2.3.2.(b)</a> for an exception, where both methods have slightly different signatures).
</p>
<div class="codecomment">
In <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a> the role <code>R1</code> in team <code>T</code>
overrides the implicitly inherited method <code>m()</code> from <code>S</code>. <code><strong>tsuper</strong>.m()</code> calls the overridden method <code>m()</code>
from <code>S.R1</code> (line 13).
</div>
</div>
<div class="subsect depth4" id="s1.3.1.g">
<h4 class="subsect">(g)&nbsp;<span class="title">Implicitly inheriting super-types</span><a class="img" href="s1.html#s1.3.1.g"
title="PermaLink to (g)&nbsp;Implicitly inheriting super-types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>If a role class has an explicit super class (using <code>extends</code>)
this relation is inherited along implicit inheritance.
</p>
<div class="codecomment">
In <a href="#l1.3.1-1" class="listing">Listing 1.3.1-1</a> the role <code>R1</code> in <code>T</code> has <code>T.R0</code>
as its implicitly inherited super class, because the corresponding role in the super-team
<code><strong>extends R0</strong></code> (line 3).
</div>
<p>Overriding an implicitly inherited super class is governed by
<a href="#s1.3.2.b"
title="&sect;1.3.2.(b)&nbsp;Inheriting and overriding the extends clause"
class="sect">&sect;1.3.2.(b)</a>, below.<br />
The list of implemented interfaces is merged along implicit
inheritance.
</p>
</div>
<div class="subsect depth4" id="s1.3.1.h">
<h4 class="subsect">(h)&nbsp;<span class="title">Preserving visibility</span><a class="img" href="s1.html#s1.3.1.h"
title="PermaLink to (h)&nbsp;Preserving visibility"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A role class must provide at least as much access as the implicit super role,
or a compile-time error occurs (this is in analogy to <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#227965"
class="ext">JLS &sect;8.4.6.3</a>).
Access rights of methods overridden by implicit inheritance follow
the same rules as for normal overriding.
</p>
</div>
<div class="subsect depth4" id="s1.3.1.i">
<h4 class="subsect">(i)&nbsp;<span class="title">Dynamic binding of constructors</span><a class="img" href="s1.html#s1.3.1.i"
title="PermaLink to (i)&nbsp;Dynamic binding of constructors"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>When creating a role instance using <code>new</code> not only the
type to instantiate is bound dynamically (cf. <a href="#s1.3.1.e" title="&sect;1.3.1.(e)&nbsp;Dynamic binding of types"
class="sect">&sect;1.3.1.(e)</a>), but also the constructor to
invoke is dynamically bound in accordance to the concrete
type.<br />
Within role constructors all <code>this(..)</code> and
<code>super(..)</code> calls are bound statically with respect to explicit inheritance
and dynamically with respect to implicit inheritance. This means the target role name is
determined statically, but using that name the suitable role type is determined
using dynamic binding.
<br />
See also <a href="s2.html#s2.5.a"
title="&sect;2.5.(a)&nbsp;Using abstract classes for creation"
class="sect">&sect;2.5.(a)</a> on using constructors of abstract role classes.
</p>
</div>
<div class="subsect depth4" id="s1.3.1.j">
<h4 class="subsect">(j)&nbsp;<span class="title">Overriding and compatibility</span><a class="img" href="s1.html#s1.3.1.j"
title="PermaLink to (j)&nbsp;Overriding and compatibility"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>The rules of <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#228745"
class="ext">JLS &sect;8.4.6</a>
also apply to methods <em>and constructors</em> inherited via implicit inheritance.
</p>
</div>
<div class="subsect depth4" id="s1.3.1.k">
<h4 class="subsect">(k)&nbsp;<span class="title">Covariant return types</span><a class="img" href="s1.html#s1.3.1.k"
title="PermaLink to (k)&nbsp;Covariant return types"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Given a team <code>T1</code> with two roles <code>R1</code> and <code>R2</code> where <code>R2</code> explicitly inherits from <code>R1</code>, both roles defining
a method <code>m</code> returning some type <code>A</code>.
Given also a sub-team of <code>T1</code>, <code>T2</code>, where <code>T2.R1</code> overrides <code>m</code> with a covariant return type <code>B</code>
(sub-type of <code>A</code>):
</p>
<div class="listing plain"><pre> <b>public</b> <b>team</b> <b>class</b> T1 {
<b>protected</b> <b>abstract</b> <b>class</b> R1 {
<b>abstract</b> A m();
}
<b>protected</b> <b>class</b> R2 <b>extends</b> R1 {
A m() { <b>return</b> <b>new</b> A(); }
}
}
<b>public</b> <b>team</b> <b>class</b> T2 <b>extends</b> T1 {
<b>protected</b> <b>class</b> R1 {
@Override B m() { <b>return</b> <b>new</b> B(); } <span class="error">// this declaration renders <b>class</b> T2.R2 illegal</span>
}
}</pre></div>
<p>
In this situation role <code>T2.R2</code> will be illegal unless also overriding <code>m</code> with a return type that is at least <code>B</code>.
Note, that the actual error occurs at the implicitly inherited method <code>T2.R2.m</code> which is not visible in the source code,
even <code>T2.R2</code> need not be mentioned explicitly in the source code.
A compiler should flag this as an imcompatibility at the team level, because a team must specialize inherited roles
in a consistent way.
</p>
</div>
<h5 class="listing">Example code (Teams and Roles):</h5>
<div class="listing example frame" id="l1.3.1-3">
<table class="listing">
<tr class="line odd">
<td class="ln">1</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> MyTeamA {</pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre> <b>protected</b> <b>class</b> MyRole {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre> String name;</pre></td>
</tr>
<tr class="line even">
<td class="ln">4</td>
<td><pre> <b>public</b> MyRole (String n) { name = n; }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">5</td>
<td><pre> <b>public</b> <b>void</b> print() { System.out.println("id="+name); }</pre></td>
</tr>
<tr class="line even">
<td class="ln">6</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">7</td>
<td><pre> <b>protected</b> MyRole getRole() { <b>return</b> <b>new</b> MyRole("Joe"); }</pre></td>
</tr>
<tr class="line even">
<td class="ln">8</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<div class="listing example frame" id="l1.3.1-4">
<table class="listing">
<tr class="line odd">
<td class="ln">10</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> MySubTeam <b>extends</b> MyTeamA {</pre></td>
</tr>
<tr class="line even">
<td class="ln">11</td>
<td><pre> <b>protected</b> <b>class</b> MyRole {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">12</td>
<td><pre> <b>int</b> age;</pre></td>
</tr>
<tr class="line even">
<td class="ln">13</td>
<td><pre> <b>public</b> <b>void</b> setAge(<b>int</b> a) { age = a; }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">14</td>
<td><pre> <b>public</b> <b>void</b> print() {</pre></td>
</tr>
<tr class="line even">
<td class="ln">15</td>
<td><pre> tsuper.print();</pre></td>
</tr>
<tr class="line odd">
<td class="ln">16</td>
<td><pre> System.out.println("age="+age);</pre></td>
</tr>
<tr class="line even">
<td class="ln">17</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">18</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">19</td>
<td><pre> <b>public</b> <b>void</b> doit() {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">20</td>
<td><pre> MyRole r = getRole();</pre></td>
</tr>
<tr class="line even">
<td class="ln">21</td>
<td><pre> r.setAge(27);</pre></td>
</tr>
<tr class="line odd">
<td class="ln">22</td>
<td><pre> r.print();</pre></td>
</tr>
<tr class="line even">
<td class="ln">23</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">24</td>
<td><pre>}</pre></td>
</tr>
<tr class="line even">
<td class="ln">25</td>
<td><pre>...</pre></td>
</tr>
<tr class="line odd">
<td class="ln">26</td>
<td><pre>MySubTeam myTeam = <b>new</b> MySubTeam();</pre></td>
</tr>
<tr class="line even">
<td class="ln">27</td>
<td><pre>myTeam.doit();</pre></td>
</tr>
</table>
</div>
<h5 class="listing">Program output</h5>
<div class="listing example frame"><pre>id=Joe
age=27</pre></div>
<div class="codecomment">
<h5>Effects:</h5>
<ul>
<li>According to <a href="#s1.3"
title="&sect;1.3&nbsp;Acquisition and implicit inheritance of role classes"
class="sect">&sect;1.3</a>, <code>MyTeamA</code> implements
<code>ITeam</code> (line 1).
</li>
<li>An implicit role inheritance is created for
<code>MySubTeam.MyRole</code> (<a href="#s1.3.1.c"
title="&sect;1.3.1.(c)&nbsp;Overriding and implicit inheritance"
class="sect">&sect;1.3.1.(c)</a>; line&nbsp;11).<br />
If we visualize this special inheritance using a fictitious keyword
<code>overrides</code> the compiler would see a declaration:
<div class="listing plain"><pre><b>protected</b> <b>class</b> MyRole <em>overrides MyTeamA.MyRole</em> { ... }</pre></div>
</li>
<li>Invoking <code>getRole()</code> on <code>myTeam</code> (line&nbsp;27, 20)
creates an instance of <code>MySubTeam.MyRole</code> because the
acquired role <code>MyTeamA.MyRole</code> is overridden by
<code>MySubTeam.MyRole</code>
following the rules of implicit inheritance (cf. <a href="#s1.3.1.e" title="&sect;1.3.1.(e)&nbsp;Dynamic binding of types"
class="sect">&sect;1.3.1.(e)</a>).
</li>
<li>Overriding of role methods and access to inherited features works as usual.
</li>
<li>As an example for <a href="#s1.3.1.f" title="&sect;1.3.1.(f)&nbsp;tsuper" class="sect">&sect;1.3.1.(f)</a> see the call <code>tsuper.print()</code>
(line&nbsp;15), which selects the implementation of <code>MyTeamA.MyRole.print</code>.
</li>
</ul>
</div>
</div>
<div class="sect depth3" id="s1.3.2">
<h3 class="sect">&sect;1.3.2&nbsp;Regular role inheritance<a class="img" href="s1.html#s1.3.2"
title="PermaLink to &sect;1.3.2&nbsp;Regular role inheritance"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#s1.3">&uarr;&nbsp;&sect;1.3</a></span></h3>
<p>In addition to implicit inheritance, roles may also inherit using
the standard Java keyword <code>extends</code>. These restrictions apply:
</p>
<div class="subsect depth4" id="s1.3.2.a">
<h4 class="subsect">(a)&nbsp;<span class="title">Super-class restrictions</span><a class="img" href="s1.html#s1.3.2.a"
title="PermaLink to (a)&nbsp;Super-class restrictions"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>If the super-class of a role is again a role it must be a direct role of
an enclosing team
This rule is simply enforced by disallowing type anchors in the
<code>extends</code> clause
(see <a href="#s1.2.2.g" title="&sect;1.2.2.(g)&nbsp;Legal contexts" class="sect">&sect;1.2.2.(g)</a>).
As an effect, the super-class may never be more deeply nested than the sub-class.
</p>
</div>
<div class="subsect depth4" id="s1.3.2.b">
<h4 class="subsect">(b)&nbsp;<span class="title">Inheriting and overriding the extends clause</span><a class="img" href="s1.html#s1.3.2.b"
title="PermaLink to (b)&nbsp;Inheriting and overriding the extends clause"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>If a role overrides another role by implicit inheritance, it may
change the inherited <code>extends</code> clause
(see <a href="#s1.3.1.g"
title="&sect;1.3.1.(g)&nbsp;Implicitly inheriting super-types"
class="sect">&sect;1.3.1.(g)</a> above) only if the new super-class
is a sub-class of the class in the overridden extends clause.
I.e., an implicit sub-role may <em>specialize</em> the extends clause of its
implicit super-role.
</p>
</div>
<div class="subsect depth4" id="s1.3.2.c">
<h4 class="subsect">(c)&nbsp;<span class="title">Constructors and overridden 'extends' </span><a class="img" href="s1.html#s1.3.2.c"
title="PermaLink to (c)&nbsp;Constructors and overridden 'extends' "><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Each constructor of a role class that overrides the extends clause of its
implicit super-role must invoke a constructor of this newly introduced
explicit super-class. Thus it may not use a <code>tsuper</code> constructor
(see <a href="s2.html#s2.4.2"
title="&sect;2.4.2&nbsp;Role creation via a regular constructor"
class="sect">&sect;2.4.2</a>).
</p>
</div>
<div class="subsect depth4" id="s1.3.2.d">
<h4 class="subsect">(d)&nbsp;<span class="title">Adding implemented interfaces</span><a class="img" href="s1.html#s1.3.2.d"
title="PermaLink to (d)&nbsp;Adding implemented interfaces"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p><code>implements</code> declarations are additive, i.e., an implicit
sub-role may add more interfaces but has to implement all interfaces of
its implicit super-role, too.
</p>
</div>
<div class="subsect depth4" id="s1.3.2.e">
<h4 class="subsect">(e)&nbsp;<span class="title">Visibility of inherited methods</span><a class="img" href="s1.html#s1.3.2.e"
title="PermaLink to (e)&nbsp;Visibility of inherited methods"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>
When a role inherits non-public methods from a regular class (as its super class),
these methods are considered as private for the role, i.e., they can only be
accessed in an unqualified method call <code>m()</code> using the implicit receiver <code>this</code>.
</p>
</div>
</div>
</div>
<div class="sect depth2" id="s1.4">
<h2 class="sect">&sect;1.4&nbsp;Name clashes<a class="img" href="s1.html#s1.4"
title="PermaLink to &sect;1.4&nbsp;Name clashes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#top">&uarr;&nbsp;&sect;1</a></span></h2>
<p>OT/J restricts Java with respect to handling of conflicting names.
</p>
<div class="subsect depth3" id="s1.4.a">
<h4 class="subsect">(a)&nbsp;<span class="title">Names of role classes</span><a class="img" href="s1.html#s1.4.a"
title="PermaLink to (a)&nbsp;Names of role classes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A role class may not have the same name as a method or field of
its enclosing team. A role class may not shadow another class that is visible in the scope of the enclosing team.
</p>
</div>
<div class="subsect depth3" id="s1.4.b">
<h4 class="subsect">(b)&nbsp;<span class="title">Names of role methods and fields</span><a class="img" href="s1.html#s1.4.b"
title="PermaLink to (b)&nbsp;Names of role methods and fields"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>Along implicit inheritance, the names of methods or fields may
not hide, shadow or obscure any previously visible name.<br />
(see JLS <a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#40898"
class="ext">&sect;8.3</a>,
<a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#227928"
class="ext">&sect;8.4.6.2</a>,
<a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#246026"
class="ext">&sect;8.5</a>,
<a href="http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#78642"
class="ext">&sect;9.3</a>,
<a href="http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#252566"
class="ext">&sect;9.5</a> (hiding),
<a href="http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html#34133"
class="ext">&sect;6.3.1</a> (shadowing),
<a href="http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html#104058"
class="ext">&sect;6.3.2</a> (obscuring).
</p>
</div>
</div>
<div class="sect depth2" id="s1.5">
<h2 class="sect">&sect;1.5&nbsp;Team and role nesting<a class="img" href="s1.html#s1.5"
title="PermaLink to &sect;1.5&nbsp;Team and role nesting"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a><span class="toplink"><a href="#top">&uarr;&nbsp;&sect;1</a></span></h2>
<p>Multi-level nesting of classes is restricted only by the following rules.
</p>
<h5 class="listing">Example code (Nesting):</h5>
<div class="listing example frame" id="l1.5">
<table class="listing">
<tr class="line odd">
<td class="ln">1</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> SuperOuter {</pre></td>
</tr>
<tr class="line even">
<td class="ln">2</td>
<td><pre> <b>public</b> <em><b>team</b> <b>class</b> RoleAndTeam</em> {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">3</td>
<td><pre> <b>protected</b> <b>class</b> InnerRole {</pre></td>
</tr>
<tr class="line even">
<td class="ln">4</td>
<td><pre> Runnable foo() { <b>return</b> null; }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">5</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">6</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">7</td>
<td><pre> <b>public</b> <em><b>team</b> <b>class</b> RoleAndTeamSub</em> <b>extends</b> <strong>RoleAndTeam</strong> {</pre></td>
</tr>
<tr class="line even">
<td class="ln">8</td>
<td><pre> <b>protected</b> <b>class</b> InnerRole {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">9</td>
<td><pre> Runnable foo() { <b>throw</b> <b>new</b> RuntimeException(); }</pre></td>
</tr>
<tr class="line even">
<td class="ln">10</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">11</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">12</td>
<td><pre>}</pre></td>
</tr>
<tr class="line odd">
<td class="ln">13</td>
<td><pre><b>public</b> <b>team</b> <b>class</b> OuterTeam <b>extends</b> SuperOuter {</pre></td>
</tr>
<tr class="line even">
<td class="ln">14</td>
<td><pre> <b>public</b> <em><b>team</b> <b>class</b> RoleAndTeam</em> {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">15</td>
<td><pre> <b>protected</b> <b>class</b> InnerRole {</pre></td>
</tr>
<tr class="line even">
<td class="ln">16</td>
<td><pre> Runnable foo() {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">17</td>
<td><pre> <b>class</b> Local {};</pre></td>
</tr>
<tr class="line even">
<td class="ln">18</td>
<td><pre> <b>return</b> <b>new</b> Runnable() { <span class="comment">// anonymous class definition</span></pre></td>
</tr>
<tr class="line odd">
<td class="ln">19</td>
<td><pre> <b>public</b> <b>void</b> run() {}</pre></td>
</tr>
<tr class="line even">
<td class="ln">20</td>
<td><pre> };</pre></td>
</tr>
<tr class="line odd">
<td class="ln">21</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">22</td>
<td><pre> <span class="comment">// <span class="error">class IllegalMember {}</span></span></pre></td>
</tr>
<tr class="line odd">
<td class="ln">23</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">24</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">25</td>
<td><pre> <b>public</b> <em><b>team</b> <b>class</b> RoleAndTeamSub</em> {</pre></td>
</tr>
<tr class="line even">
<td class="ln">26</td>
<td><pre> <b>protected</b> <b>class</b> InnerRole {</pre></td>
</tr>
<tr class="line odd">
<td class="ln">27</td>
<td><pre> Runnable foo() {</pre></td>
</tr>
<tr class="line even">
<td class="ln">28</td>
<td><pre> <em>RoleAndTeamSub.tsuper</em>.foo();</pre></td>
</tr>
<tr class="line odd">
<td class="ln">29</td>
<td><pre> <b>return</b> <em>OuterTeam.tsuper</em>.foo();</pre></td>
</tr>
<tr class="line even">
<td class="ln">30</td>
<td><pre> };</pre></td>
</tr>
<tr class="line odd">
<td class="ln">31</td>
<td><pre> }</pre></td>
</tr>
<tr class="line even">
<td class="ln">32</td>
<td><pre> }</pre></td>
</tr>
<tr class="line odd">
<td class="ln">33</td>
<td><pre>}</pre></td>
</tr>
</table>
</div>
<div class="subsect depth3" id="s1.5.a">
<h4 class="subsect">(a)&nbsp;<span class="title">Nested teams</span><a class="img" href="s1.html#s1.5.a" title="PermaLink to (a)&nbsp;Nested teams"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>If a role class is also marked using the <code>team</code> modifier,
it may contain roles at the next level of nesting.
</p>
<div class="codecomment">
<ul>
<li>In the above example (<a href="#l1.5" class="listing">Listing 1.5</a>) class <code>RoleAndTeam</code> starting in line 14
is a role of <code>OuterTeam</code> and at the same time a
team containing a further role <code>InnerRole</code></li>
</ul>
</div>
<p>Such a hybrid role-and-team has all properties of both kinds of classes.
</p>
</div>
<div class="subsect depth3" id="s1.5.b">
<h4 class="subsect">(b)&nbsp;<span class="title">Nested classes of roles</span><a class="img" href="s1.html#s1.5.b"
title="PermaLink to (b)&nbsp;Nested classes of roles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A regular role class (ie., not marked as <code>team</code>, see above)
may contain local types (see <a href="http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#247766"
class="ext">JLS &sect;14.3</a>
- in the example: class <code>Local</code>), anonymous types
(<a href="http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#252986"
class="ext">JLS &sect;15.9.5</a>
- in the example: class defined in lines 18-20)
but no member types (<a href="http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#246026"
class="ext">JLS &sect;8.5</a>
- in the example: illegal class
<code>IllegalMember</code>).
<br />
The effect is, that nested types of a regular role cannot be
used outside the scope of their enclosing role.
</p>
</div>
<div class="subsect depth3" id="s1.5.c">
<h4 class="subsect">(c)&nbsp;<span class="title">Prohibition of cycles</span><a class="img" href="s1.html#s1.5.c"
title="PermaLink to (c)&nbsp;Prohibition of cycles"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A nested team may not extend its own enclosing team.
</p>
</div>
<div class="subsect depth3" id="s1.5.d">
<h4 class="subsect">(d)&nbsp;<span class="title">Prohibition of name clashes</span><a class="img" href="s1.html#s1.5.d"
title="PermaLink to (d)&nbsp;Prohibition of name clashes"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A nested team may inherit roles from multiple sources: its explicit super team
and any of its implicit super classes (roles) from different levels of nesting.
If from different sources a team inherits two or more roles of the same name
that are not related by implicit inheritance, this is an illegal name clash.
</p>
</div>
<div class="subsect depth3" id="s1.5.e">
<h4 class="subsect">(e)&nbsp;<span class="title">Precedence among different supers</span><a class="img" href="s1.html#s1.5.e"
title="PermaLink to (e)&nbsp;Precedence among different supers"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>If a role inherits the same feature from several super roles (super and tsuper),
an implicitly inherited version always overrides any explicitly inherited feature,
i.e., a role with the same simple name is closer related than one with a different name.
</p>
<p>
Also implicit inheritance alone may produce several candidate methods inherited by a role class.
This is a result of team-nesting where each level of nesting may add one more tsuper role
if outer teams also participate in an inheritance relationship.
In this case a role inherited from an <em>implicit</em> super team of the enclosing team
is closer related than a role inherited from an <em>explicit</em> super team.
If necessary this rule is applied inside out until a nesting level is found where indeed
explicit team inheritance is involved.<br />
So when comparing classes by their fully qualified names
the longest common suffix will determine the closest relationship.
E.g., <code>SuperOuter.RoleAndTeamSub.InnerRole</code>
is the closest ancestor of <code>SubOuter.RoleAndTeamSub.InnerRole</code>
because both share the name suffix <code>RoleAndTeamSub.InnerRole</code>.
</p>
<div class="codecomment">
<table>
<colgroup span="1">
<col align="left" span="1" />
<col align="center" span="1" />
</colgroup>
<tr>
<td valign="top" rowspan="1" colspan="1">
<p>In the above example (<a href="#l1.5" class="listing">Listing 1.5</a>) role <code class="small">OuterTeam.RoleAndTeamSub.InnerRole</code>
has two direct tsuper roles:
<code class="small">OuterTeam.RoleAndTeam.InnerRole</code>&nbsp;and <code class="small">SuperOuter.RoleAndTeamSub.InnerRole</code>.
Without the method <code>foo</code> defined in lines 27-30, the enclosing class <code class="small">OuterTeam.RoleAndTeamSub.InnerRole</code>
would inherit the method <code>foo</code> defined in <code>SuperOuter.RoleAndTeamSub.InnerRole</code> (line 9),
because the common name suffix <code>RoleAndTeamSub.InnerRole</code>
creates a stronger relationship making that class the closest ancestor.
</p>
</td>
<td rowspan="1" colspan="1"><img src="../images/team_nesting_hor.png" alt="Example diagram team nesting" /></td>
</tr>
</table>
</div>
</div>
<div class="subsect depth3" id="s1.5.f">
<h4 class="subsect">(f)&nbsp;<span class="title">Qualified tsuper</span><a class="img" href="s1.html#s1.5.f"
title="PermaLink to (f)&nbsp;Qualified tsuper"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png"
alt="" /></a></h4>
<p>A role in a nested team may qualify the keyword <code>tsuper</code> (see <a href="#s1.3.1.f" title="&sect;1.3.1.(f)&nbsp;tsuper" class="sect">&sect;1.3.1.(f)</a> above) by a type name
in order to select among different implicit super classes.
A term <code>OuterTeam.tsuper</code> evaluates to a corresponding implicit super class
within the context of the explicit super-class (here: <code>SuperOuter</code>) of the enclosing team "<code>OuterTeam</code>".
A method call <code>OuterTeam.tsuper.m()</code>
evaluates to the method version within <code>SuperOuter</code> that best corresponds to the current method containing the tsuper-call.
</p>
<div class="codecomment">
<ul>
<li>In the above example (<a href="#l1.5" class="listing">Listing 1.5</a>) line 28 selects the method version
within the superclass of <code>RoleAndTeamSub</code> (i.e., within <code>RoleAndTeam</code>),
resolving to <code>OuterTeam.RoleAndTeam.InnerRole.foo()</code>.
</li>
<li>Line 29 selects a corresponding method from the context of <code>SuperOuter</code> resolving to <code>SuperOuter.RoleAndTeamSub.InnerRole.foo()</code>
which has the same semantics as an unqualified <code>tsuper</code> call would have.
</li>
</ul>
</div>
</div>
</div>
<div class="aux" id="aux1.1">
<h4 class="aux">Language implementation:<span class="toplink"><a href="#s1">&uarr;&nbsp;&sect;1</a></span></h4>
<p>Role acquisition and implicit inheritance can be implemented in at least two ways.
</p>
<p><strong>Virtual classes:</strong> Each role class is an overridable feature of
its enclosing team. Role classes are resolved by dynamic binding
with respect to the enclosing team instance. This implementation
requires multiple-inheritance in order to also allow regular
inheritance between roles of the same team. <code>super</code>
and <code>tsuper</code> select parent versions of a method along
the two dimensions of inheritance.
</p>
<p><strong>Copy inheritance:</strong> Role acquisition from a super-team has the effect
of copying a role definition <code>T.R</code> yielding a new
role <code>Tsub.R</code>. All role applications <code>Rx</code>
in the role copy refer to <code>Tsub.Rx</code>. Implicit role
inheritance extends a role copy in-place. Only the <code>tsuper</code>
construct allows to access the previous version of a method
(i.e. before in-place overriding).
</p>
</div>
<div class="aux" id="aux1.2">
<h4 class="aux">References:<span class="toplink"><a href="#s1">&uarr;&nbsp;&sect;1</a></span></h4>
<p id="fn1-virtual-classes">[1] Ole Lehrmann Madsen and Birger M&oslash;ller-Pedersen. <em>Virtual classes: A powerful mechanism in object-oriented programming</em>. In Proceedings OOPSLA 89, ACM SIGPLAN Notices, volume 24, 10, pages 397-406, October 1989.
</p>
<p id="fn2-family-polymorphism">[2] Erik Ernst. <em>Family Polymorphism.</em> In Proceedings ECOOP 2001, LNCS 2072, pages 303-326, Springer, 2001.
</p>
</div>
</div>
<table class="nav">
<tr>
<td class="back"><a href="s0.html" rel="prev">&lt;&lt;&nbsp;&sect;0&nbsp;About this Document</a></td>
<td class="top"><a href="index.html" rel="contents">&uarr;&nbsp;Table of Contents&nbsp;&uarr;</a></td>
<td class="next"><a href="s2.html" rel="next">&sect;2&nbsp;Role Binding&nbsp;&gt;&gt;</a></td>
</tr>
</table>
</div>
<div id="footer">
<hr /><a class="w3c img" href="http://jigsaw.w3.org/css-validator/check/referer"
shape="rect"><img src="../images/valid-css2-blue.png" alt="Valid CSS!" height="31" width="88" /></a><a class="w3c img" href="http://validator.w3.org/check?uri=referer" shape="rect"><img src="../images/valid-xhtml10-blue.png" alt="Valid XHTML 1.0 Strict" height="31"
width="88" /></a><address>&copy; Stephan Herrmann, Christine Hundt, Marco Mosconi</address>
OT/J version 1.3.1 &mdash; last modified: 2013-05-28
</div>
</body>
</html>