| <!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</title> |
| </head> |
| <body class="otdt"> |
| <div id="content"> |
| <table class="nav"> |
| <tr> |
| <td class="back"><a id="top"></a><a href="sB.1.2.html" rel="prev"><< §B.1.(2) Between OTJLD 1.1 and OTJLD 1.2</a></td> |
| <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td> |
| <td class="next"></td> |
| </tr> |
| </table> |
| <div class="breadcrumb"><a class="nav" href="sB.html" rel="section">§B Changes between versions</a> > <a class="nav" href="sB.1.html" rel="section">§B.1 Paragraphs changed between versions</a></div> |
| <div class="subsect depth3" id="sB.1.3"> |
| <h4 class="subsect">§B.1.(3) <span class="title">Between OTJLD 1.2 and OTJLD 1.3</span><a class="img" href="sB.1.3.html" |
| title="PermaLink to (3) Between OTJLD 1.2 and OTJLD 1.3"><img style="vertical-align:text-top;margin-left:5px;" src="../images/permalink.png" |
| alt="" /></a></h4> |
| <ul> |
| <li><a href="s1.2.4.c.html" title="§1.2.4.(c) Class literal" |
| class="sect">§1.2.4.(c)</a> : |
| <strong>Syntax for role class literals</strong><p>Previously, the syntax <code>R<@t>.class</code> was not supported. |
| This restriction has been removed. |
| |
| </p> |
| </li> |
| <li><a href="s1.3.html" |
| title="§1.3 Acquisition and implicit inheritance of role classes" |
| class="sect">§1.3</a> : |
| <strong>Teams extending non-team classes</strong><p>Previously, <code>org.objectteams.Team</code> was the super class of all team classes. |
| As a consequence a team could not extend a non-team class. |
| This restriction has been removed by introducing a new super-type of all teams, |
| the interface <code>org.objectteams.ITeam</code>. |
| This change also affects some paragraphs in <a href="s6.html" title="§6 Object Teams API" class="sect">§6</a> as members |
| have been moved to the new interface. |
| |
| </p> |
| </li> |
| <li><a href="s1.5.e.html" |
| title="§1.5.(e) Precedence among different supers" |
| class="sect">§1.5.(e)</a> : |
| <strong>Precedence among different implicit supers</strong><p>Corrected an inconsistency in the rules for precedence among different supers: |
| The primary rule has always been that implicit inheritance binds stronger than explicit inheritance, |
| however, for precedence among different implicit supers a different rule was defined.<br /> |
| This has been changed such that different implicit supers are prioritized by the |
| precedence of their enclosing teams, such that a role from an <em>implicit</em> super team |
| is closer related than a role from an <em>explicit</em> super team. |
| |
| </p> |
| </li> |
| <li><a href="s2.1.2.b.html" title="§2.1.2.(b) Cycles" class="sect">§2.1.2.(b)</a> : |
| <strong>Relaxed the rule against base class circularity</strong><p>Base class circularity as defined in <a href="s2.1.2.b.html" title="§2.1.2.(b) Cycles" class="sect">§2.1.2.(b)</a> is no longer an error |
| but as a configurable warning. However, in the presence of base class circularity, neither |
| callouts (<a href="s3.1.a.html" title="§3.1.(a) Prerequisite: Class binding" |
| class="sect">§3.1.(a)</a>) nor base constructor calls (<a href="s2.4.2.html" |
| title="§2.4.2 Role creation via a regular constructor" |
| class="sect">§2.4.2</a>) |
| are allowed. |
| |
| </p> |
| </li> |
| <li><a href="s2.3.4.html" title="§2.3.4 Binding ambiguities" |
| class="sect">§2.3.4</a> : |
| <strong>Changed handling of role binding ambiguities</strong><p>A definite binding ambiguity is no longer a (suppressable) compiler error, but is signaled |
| by the need to declare <code>org.objectteams.LiftingFailedException</code>. |
| This way diagnostics could be moved from rather unspecific locations in the team |
| towards those applications that could suffer at runtime from a lifting failure. |
| While it is generally not recommended to ignore any <code>LiftingFailedException</code> |
| catching this exception may still make sense in a few corner cases mentioned in <a href="s2.3.4.b.html" title="§2.3.4.(b) Definite ambiguity" |
| class="sect">§2.3.4.(b)</a>. |
| |
| </p> |
| </li> |
| <li><a href="s4.4.c.html" |
| title="§4.4.(c) Mapping the result of a base method" |
| class="sect">§4.4.(c)</a> : |
| <strong>Further restrict result mapping in after callin bindings</strong><p>Clarify that <code>after</code> callin bindings cannot use the <code>-></code> |
| token to map a result value. |
| |
| </p> |
| </li> |
| <li><a href="s4.8.a.html" title="§4.8.(a) Precedence declaration" |
| class="sect">§4.8.(a)</a> : |
| <strong>Precedence declarations affecting <code>after</code> callin bindings.</strong><p>While previously the effect of precedence declarations was underspecified it has been |
| defined that the order of elements in a precedence declaration affects their <em>priority</em> |
| similar to <a href="s5.1.html" title="§5.1 Effect of team activation" |
| class="sect">§5.1</a>. This implies that the execution order for |
| <code>after</code> bindings is now reversed compared to the previous implementation. |
| In order to visualize this in the program it is now mandatory to mark precedence declarations |
| for after bindings with the keyword <code>after</code>. |
| |
| </p> |
| </li> |
| <li><a href="s4.10.html" title="§4.10 Generic callin bindings" |
| class="sect">§4.10</a>, <a href="s4.10.a.html" title="§4.10.(a) Fresh type parameter" |
| class="sect">§4.10.(a)</a> : |
| <strong>Generic callin bindings</strong><p>Minor changes to give room for new paragraph <a href="s4.10.e.html" title="§4.10.(e) Propagating type parameters" |
| class="sect">§4.10.(e)</a>. |
| </p> |
| </li> |
| <li><a href="s5.4.1.a.html" title="§5.4.1.(a) Method binding guards" |
| class="sect">§5.4.1.(a)</a> : |
| <strong>Scope of regular binding guard</strong><p>Removed an erroneous sentence about the special identifier <code>result</code> in a regular method binding guard. |
| Since parameter mappings are applied before evaluating the guard, the result value can be accessed through |
| a result mapping (<a href="s4.4.c.html" |
| title="§4.4.(c) Mapping the result of a base method" |
| class="sect">§4.4.(c)</a>). Furthermore, the sentence actually confused |
| base and role sides. |
| |
| </p> |
| </li> |
| <li><a href="sA.html#sA.3.2" title="§A.3.2 CalloutBinding" class="sect">§A.3.2</a>, <a href="sA.html#sA.3.3" title="§A.3.3 Callin binding" class="sect">§A.3.3</a> : |
| <strong>Syntax: generic method bindings</strong><p>The location of possible type parameters in a method binding has been made explicit.</p> |
| </li> |
| </ul> |
| </div> |
| <table class="nav"> |
| <tr> |
| <td class="back"><a href="sB.1.2.html" rel="prev"><< §B.1.(2) Between OTJLD 1.1 and OTJLD 1.2</a></td> |
| <td class="top"><a href="index.html" rel="contents">↑ Table of Contents ↑</a></td> |
| <td class="next"></td> |
| </tr> |
| </table> |
| <div class="breadcrumb"><a class="nav" href="sB.html" rel="section">§B Changes between versions</a> > <a class="nav" href="sB.1.html" rel="section">§B.1 Paragraphs changed between versions</a></div> |
| </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>© Stephan Herrmann, Christine Hundt, Marco Mosconi</address> |
| OT/J version 1.3 — last modified: 2011-05-15 |
| </div> |
| </body> |
| </html> |