| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <html> |
| <head> |
| <link rel=stylesheet type="text/css" href="../css/style.css"> |
| <link rel=stylesheet type="text/css" href="../css/nn.css"> |
| <title>OTDT 0.7.1 (Incubation) - New and Noteworthy</title> |
| </head> |
| <body> |
| <h1>OTDT 0.7.1 (Incubation) - New and Noteworthy</h1> |
| <div class="navigation"><i>Changes since the 0.7.0 Release</i></div> |
| <div class="navigation">On this page: |
| <!--a href="#metrics">• Metrics Plug-in</a--> |
| <!--a href="#configuration">• Configuration</a--> |
| <a href="#views">• Views/Dialogs</a> |
| <a href="#assist">• Content Assist</a> |
| <a href="#refactor">• Refactoring</a> |
| <!--a href="#formatting">• Formatting</a--> |
| <a href="#debug">• Run/Debug</a> |
| <a href="#language">• Language</a> |
| <a href="#api">• API</a> |
| <a href="#compiler">• Compiler</a> |
| <a href="#otre">• Runtime</a> |
| <!--a href="#otequinox">• OT/Equinox</a--> |
| </div> |
| <table cellpadding="10" cellspacing="0" width="100%"> |
| <colgroup> |
| <col width="20%"> |
| <col width="80%"> |
| </colgroup> |
| <tbody> |
| <!-- |
| <tr><td colspan="2" id="NAME"><h2>HEADING</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>DESC</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="TITLE" href="https://bugs.eclipse.org/308029">308029</a></p></td> |
| <td><p> |
| |
| </p> |
| <p><img alt="TEXT" src="../images/screenshots/NN07/.png"></p> |
| <p></p> |
| </td> |
| </tr> |
| <div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> <font color="blue">MyTeam</font> { |
| }</pre></div></div> |
| --> |
| <tr><td colspan="2" id="views"><h2>Views & Dialogs</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Traditional Hierarchy View</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="[hierarchy] revive and adjust traditional type hierarchy for OT/J " href="https://bugs.eclipse.org/322898">322898</a></p></td> |
| <td><p> |
| The "traditional" hierarchy view is a mode of the Type Hierarchy View, |
| where starting from a given focus type both the tree of subclasses and the chain of superclass |
| is rendered in a single view. Due to the fact that roles may have multiple superclasses this |
| mode was disabled in the OTDT. |
| </p> |
| <p> |
| A new adaptation of the internal <code>TypeHierarchy</code> classes allows us to |
| linearize the set of superclasses wrt the focus class, i.e., superclasses are shown |
| in the order as seen from the focus class, which prioritizes implicit inheritance |
| over explicit inheritance. |
| </p> |
| <p>E.g., consider the following code: |
| <div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> EcoSystem { |
| <code class="keyword">protected class</code> Project { } |
| <code class="keyword">protected class</code> IDEProject <code class="keyword">extends</code> Project { } |
| } |
| <code class="keyword">public team class</code> Eclipse <code class="keyword">extends</code> EcoSystem { |
| @Override |
| <code class="keyword">protected class</code> Project { } |
| @Override |
| <code class="keyword">protected class</code> <font color="blue">IDEProject</font><em class="comment">/*open Type Hierarchy here*/</em> <code class="keyword">extends</code> Project { } |
| <code class="keyword">protected class</code> CDT <code class="keyword">extends</code> IDEProject { } |
| <code class="keyword">protected class</code> JDT <code class="keyword">extends</code> IDEProject { } |
| <code class="keyword">protected class</code> OTDT <code class="keyword">extends</code> IDEProject { } |
| }</pre></div></div></p> |
| <p> |
| which yields the following rendering: |
| </p> |
| <p><img alt="TEXT" src="../images/screenshots/NN07/othierarchy.png"></p> |
| <p></p> |
| </td> |
| </tr> |
| <tr><td colspan="2" id="assist"><h2>Content assist</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Adjust callin return</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="[assist] creating before/after callin using completion should set return type to void" href="https://bugs.eclipse.org/315310">315310</a></p></td> |
| <td><p> |
| Previously, when creating a callin method using completion, the role method designator would be created with |
| the exact same return type as the bound base method. However, for before and especially after callin bindings |
| this was misleading, because any value returned by the role method would be simply ignored. |
| </p> |
| <p> |
| In order to avoid confusing the user, method binding completion now works with the following changes: |
| <ul><li>Completion generally offers the option to replace the role method return type with <code class="keyword">void</code>:</li></ul> |
| </p> |
| <p><img alt="Return type options" src="../images/screenshots/NN07/CreateMethodBinding1.png"></p> |
| <p> |
| <ul><li>Still, the binding kind <code class="keyword"><- after</code> can be selected without |
| selecting <code>void</code> as the return type:</li></ul> |
| </p> |
| <p><img alt="Selecting after" src="../images/screenshots/NN07/CreateMethodBinding2.png"></p> |
| <p> |
| <ul><li>However, when the binding kind is confirmed by hitting enter, the return type is |
| automatically adjusted to <code>void</code>:</li></ul> |
| </p> |
| <p><img alt="Created method binding" src="../images/screenshots/NN07/CreateMethodBinding3.png"></p> |
| </td> |
| </tr> |
| |
| <tr><td colspan="2" id="refactor"><h2>Refactoring</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Change Signature Refacoring</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="[refactoring] adapt "change signature" refactoring" href="https://bugs.eclipse.org/311879">311879</a></p></td> |
| <td><p> |
| The Change Signature refactoring has been adapted to work for OT/J sources, too. |
| Now, if the signature of a method is refactored that is referenced from a callout or callin method binding, |
| the binding is adjusted accordingly. The refactoring tries to absorb all changes within the binding, |
| like adding a parameter mapping to absorb a re-ordering of arguments. |
| If a change needs to be propagated through the binding (i.e., it cannot be fully absorbed) |
| the refactoring will inform the user by issuing a warning. |
| </p> |
| <p> |
| Here is a preview of a refactoring, where the signature of <code>bm</code> has been changed by |
| (a) adding an argument <code>String str</code> and (b) moving argument <code>i</code> to the end: |
| </p> |
| <p><a href="../images/screenshots/NN07/ChangeSignature2.png"><img alt="Change Signature preview" src="../images/screenshots/NN07/ChangeSignature2.png" width=800"></a></p> |
| <p></p> |
| </td> |
| </tr> |
| <tr><td colspan="2" id="debug"><h2>Run / Debug</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Stack frame beautifying</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="[debug] private role method bridge is interpreted as callin wrapper" href="https://bugs.eclipse.org/318993">318993</a></p></td> |
| <td><p> |
| The Debug View now knows about more kinds of synthetic methods generated by the OT/J compiler. |
| All these methods are beautified by replacing the internal name with a human readable explanation |
| and de-emphasizing these stack frames using a lighter color. |
| </p> |
| <p><img alt="Beautified stack frames" src="../images/screenshots/NN07/MoreDebugColoring.png"></p> |
| <p>The shaded stackframes in the above screenshot signify (from top to bottom): |
| <ul> |
| <li>Access to a private base method applying decapsulation</li> |
| <li>Invocation of a synthetic method for initializing the fields of a role</li> |
| <li>Indirect invocation of a role's constructor (late binding of the role class)</li> |
| </ul> |
| </p> |
| </td> |
| </tr> |
| <tr><td colspan="2" id="api"><h2>API</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>isActive() is now final</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="[otre] overriding Team.isActive() may cause deadlock" href="https://bugs.eclipse.org/324537">324537</a></p></td> |
| <td><p> |
| Previously, methods <code>Team.isActive()</code> and <code>Team.isActive(Thread)</code> could be overridden in sub-teams, |
| but if an overriding version did not return immediately it could cause a deadlock, |
| because the infrastructure invokes these methods from synchronized blocks. |
| </p> |
| <p>In order to avoid this risk of deadlocks, both methods have been changed to <code class="keyword">final</code>. |
| </p> |
| </td> |
| </tr> <tr><td colspan="2" id="language"><h2>Language</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Internal State Pattern</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="[otjld] [compiler] Support the "Internal Role" pattern" href="https://bugs.eclipse.org/318815">318815</a></p></td> |
| <td><p> |
| Previously, <a class="otjldlink" href="http://www.objectteams.org/def/1.2/s2.html#s2.1.2.b">OTJLD (v1.2) §2.1.2(b)</a> |
| disallowed to bind a role to its enclosing team. This rule was found to be overly cautious and prohibitive. |
| By essentially removing this restriction (except for a few corner cases), the following pattern is |
| now possible: |
| <div class="listbox"><div class="listing"><pre><code class="keyword">public team class</code> <font color="blue">MyTeam</font> { |
| <code class="keyword">public void</code> service() { ... } |
| <code class="keyword">enum</code> Mode {NORMAL, MAINTENANCE, BOOT_IN_PROGRESS}; |
| Mode mode; |
| <code class="keyword">protected class</code> MaintenanceMode <code class="keyword">playedBy</code> <font color="blue">MyTeam</font> |
| <code class="keyword">base when</code> (MyTeam.this.mode == Mode.MAINTENANCE) { |
| mainenanceNotice <code class="keyword"><- replace</code> service; |
| ... |
| } |
| <code class="keyword">protected class</code> BootingMode <code class="keyword">playedBy</code> <font color="blue">MyTeam</font> |
| <code class="keyword">base when</code> (MyTeam.this.mode == Mode.BOOT_IN_PROGRESS) { ... } |
| }</pre></div></div> |
| The point is here that both roles adapt their enclosing team <code style="color:blue;">MyTeam</code> - thus providing a very well |
| localized implementation for different states/modes of the team. |
| </p> |
| <p>Note, that the above code will cause the compiler to signal a warning: "Base class MyTeam is an enclosing type of MaintenanceMode ...", |
| which can be silenced by <code>@SuppressWarnings("baseclasscycle")</code> |
| </p> |
| <p>See also the <a href="http://wiki.eclipse.org/index.php?title=OTPattern/InnerState">Internal State Pattern</a> in the wiki.</p> |
| </td> |
| </tr> |
| <tr><td colspan="2" id="compiler"><h2>Compiler</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>playedBy Interface</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="[compiler][otre] support for role-binding to interfaces" href="https://bugs.eclipse.org/321440">321440</a></p></td> |
| <td><p> |
| The OTJLD never said that the type after <code class="keyword">playedBy</code> definitely must be a class, |
| but contained a note mentioning a compiler limitation in this regard. |
| This limitation has been weakened so that now a role can also be bound to an interface. |
| Only, in such situations the role cannot declare callin method bindings (callout is not a problem). |
| It is of course possible to define sub-roles that are bound to classes implementing the base interface |
| such that those sub-roles can declare callin bindings, too. |
| </p> |
| </td> |
| </tr> |
| |
| <tr><td colspan="2" id="otre"><h2>Object Teams Runtime Environment</h2></td></tr> |
| <tr> |
| <td><p align="right"><b>Packaged as a bundle</b><br> |
| <span class="since">since 0.7.1</span><br> |
| <a class="buglink" title="[pde] Exporting an OT plug-in requires to have org.eclipse.objectteams.runtime in the ws" href="https://bugs.eclipse.org/320191">320191</a></p></td> |
| <td><p> |
| Packaging and deployment of the OTRE has changed from a plain Jar to a regular OSGi bundle called <code>org.eclipse.objectteams.runtime</code>. |
| Yet, this bundle Jar can still be used outside any OSGi context. |
| While this simplifies several build and deploy issues, the change should be mostly transparent for users. |
| Only when compiling/running OT/J applications outside Eclipse script will need adjusting to refer |
| to the bundle Jar instead of the old <code>otre.jar</code>. |
| </p> |
| </td> |
| </tr> |
| |
| </table> |
| </body> |