OTDT 2.2 - New and Noteworthy

Views & Dialogs

OT elements in structure compare
since 2.2
408460

Object Teams elements are now properly displayed in structure comparisons of any compare editors.

Refactoring

Pull-up callout bindings
since 2.2M1
386587
386814

The pull-up refactoring has been made smarter so that it can correctly handle callout method bindings, too.

A callout binding can either be pulled-up as such or a corresponding abstract method can be created in ths super-role.

When choosing among the above strategies in the wizard, pull-up will only be accepted if a super-role has a compatible playedBy binding.

This is particularly interesting when pulling up a method that calls a callout:

Pull-up:

public team class T {
  protected class R0 playedBy B {
  }
  protected class R1 extends R0 {
    void foo() -> void bar();
    void test() {
      foo();
    }
  }
}

public team class T {
  protected class R0 playedBy B {
    void foo() -> void bar();
    void test() {
      foo();
    }
  }
  protected class R1 extends R0 {
  }
}

Declare abstract:

public team class T {
  protected class R0 {
  }
  protected class R1 extends R0
                     playedBy B {
    void foo() -> void bar();
    void test() {
      foo();
    }
  }
}

public team class T {
  protected abstract class R0 {
    abstract void foo();
    void test() {
      foo();
    }
  }
  protected class R1 extends R0
                     playedBy B {
    void foo() -> void bar();
  }
}

In the latter example you see that test() can be successfully pulled up, although no implementation for foo() is available in the super role R0.

Move to role file
since 2.2M7
382186

A new refactoring has been added to move an inline role to a new role file (see OTJLD §1.2.5).

This refactoring is relevant when a team with inline roles grows to a size where maintainability suffers from a lack of decomposition. Since teams typically start with only a few, small roles, it is natural that this issue arises only during evolution. Re-organizing the file structure using this new refactoring is the natural answer to such issues.

By definition this refactoring does not change the semantics of a program. Still the following items are considered by the refactoring:

• Create the folder representing the team package, if necessary.
• Insert a @role javadoc tag into the team class. This serves as an index of role files logically contained in a team, and thus facilitates navigation (F3) and helps the compiler during incremental compilation.
• Try to identify comments before and after the role class which likely belong to the role class and thus should be moved to the new file, too.

The refactoring is invoked via the Refactor menu or context menu as Move to Role File. No further input is needed.

Language

Callin to Constructor
since 2.2
316616

It is now possible to define a callin-after binding to a constructor of a role's base class:

class SomeBase {
  SomeBase() {
    // ... body omitted
  }
}
public team class T {
  protected class R playedBy SomeBase {
    void test() <- after SomeBase();
    void test() {
      // ... body omitted
    }
  }
}

Within the intercepting role method the base instance can be assumed to be fully initialized, and thus the role is fully operational, e.g., in terms of calling callout-bound methods. It is for these reasons that before and replace bindings are not allowed for constructors: the base instance wouldn't be accessible and thus the role cannot yet be created at this point.