Latest News

§4 Callin Binding

Notion of callin binding

Callin bindings realize a forwarding in the direction opposite to callout bindings (see §3). Both terms are chosen from the perspective of a role, which controls its communication with an associated base object. Technically, callin bindings are equivalent to weaving additional code (triggers) into existing base methods.

Callin
Methods of a base class may be intercepted by a callin binding (the base method "calls into" the role).
Before/after/replace
The modifiers before, after, replace control the composition of original method and callin method.
Activation
Callin bindings may be active or inactive according to §5.

§4.1 Callin method binding↑ §4

(a) Method call interception

A role method may intercept calls to a base method by a callin binding.

(b) Prerequisite: Class binding

A callin binding requires the enclosing class to be a role class bound to a base class according to §2.1. An unliftable role (see §2.3.4.(a)) should not define callin bindings. In this case callin bindings can only safely be introduced in sub-roles which (by an appropriately refined playedBy clause) disambiguate the lifting translation.

For corner cases the above rule can be overridden by suppressing the corresponding error using the "hidden-lifting-problem" token (see §2.3.5). This will allow callin bindings to be defined even for unliftable roles expecting that lifting may still succeed by one of the patterns desribed in §2.3.4.(b).

(c) Callin declaration

A callin binding composes an existing role method with a given base method. It may appear within the role class at any place where feature declarations are allowed. It is denoted by

role_method_designator <- callin_modifier base_method_designator;

Just like with callout bindings, method designators may or may not contain parameters lists and return type but no modifiers; also, each method designator must exactly and uniquely select one method (cf. §3.1.(c)).
For callin modifiers see below (§4.2).

(d) Multiple base methods

Base method designators may furthermore enumerate a list of methods. If multiple base methods are bound in one callin declaration generally all signatures in this binding must be conform.
However, extraneous parameters from base methods may be ignored at the role.
For result types different rules exist, depending on the applied callin modifier (see next).

(e) Named callin binding

Any callin binding may be labeled with a name. The name of a callin binding is used for declaring precedence (§4.8). A named callin binding overrides any inherited callin binding (explicit and implicit (§1.3.1)) with the same name.
It is an error to use the same callin name more than once within the same role class.

(f) Callin to final

When binding to a final base method, the enclosing role must be played by the exact base class declaring the final method. I.e., callin binding to a final method inherited from the base class's super-class is not allowed. This is motivated by the fact that no sub-class may have a version of a final method with different semantics.

(g) Declared exceptions

It is an error if a role method to be bound by callin declares in its throws clause any exceptions that are not declared by the corresponding base method(s).

(h) Method of enclosing class

In a before or after callin binding the left hand side may alternatively resolve to a method of an enclosing class rather than the current role.

(i) Callin to constructor

A callin binding may refer to a constructor of the bound base class by using the constructor's source name (identical to the name of the base class). In this case only an after binding (§4.2.(a)) is allowed.

§4.2 Callin modifiers (before, after, replace)↑ §4

(a) Method composition

The kind of method composition is controlled by adding one of the modifiers before, after or replace after the "<-" token of the binding declaration.

(b) Additive composition

The before and after modifiers have the effect of adding a call to the role method at the beginning or end of the base method, resp.
In this case no data are transferred from the role to the base, so if the role method has a result, this will always be ignored.

Example code (Callin):
1
team class Company {
2
  protected class Employee playedBy Person {
3
    public void recalculateIncome() { ... }
4
    recalculateIncome <- after haveBirthday; // callin binding
5
  }
6
}

Line 4 declares a callin binding for the role method recalculateIncome() defined in line 3. In combination with the role binding in line 2 this has the following effect:

  • After every call of the method Person.haveBirthday the method Company.recalculateIncome is called.

(c) Replacing composition

The replace modifier causes only the role method to be invoked, replacing the base method.
In this case, if the base method declares a result, this should be provided by the role method. Special cases of return values in callin bindings are discussed in §4.3.(e)

(d) Callin methods

Role methods to be bound by a callin replacement binding must have the modifier callin. This modifier is only allowed for methods of a role class.
A method with the callin modifier can only be called

  • via a callin replace binding
  • by a super or tsuper call from an overriding callin method.

It is illegal for a callin method

  • to be called directly,
  • to be bound using a callout binding, and
  • to be bound to a base method using a before or after callin binding.

Despite these rules a second level role — which is played by the current role — can intercept the execution of a callin method using any form of callin binding.

A callin method cannot override a regular method and vice versa, however, overriding one callin method with another callin method is legal and dynamic binding applies to callin method just like regular methods.
A callin method must not declare its visibility using any of the modifiers public, protected or private. Since callin methods can only be invoked via callin bindings such visibility control would not be useful.

§4.3 Base calls↑ §4

Role methods with a callin modifier should contain a base call which uses the special name base in order to invoke the original base method (original means: before replacement).

(a) Syntax

The syntax for base calls is base.m(), which is in analogy to super calls. A base.m() call must use the same name and signature as the enclosing method. This again follows the rule, that roles should never explicitly use base names, except in binding declarations.

(b) Missing base call

For each callin method, the compiler uses some flow analysis to check whether a base call will be invoked on each path of execution (analysis is very similar to the analysis for definite assignment regarding final variables - JLS §16). The compiler will issue a warning if a base call is missing either on each path (definitely missing) or on some paths (potentially missing). Instead of directly invoking a base call, a callin method may also call its explicit or implicit super version using super.m() or tsuper.m() (see §1.3.1.(f)). In this case the flow analysis will transitively include the called super/tsuper version.

(c) Duplicate base call

If a callin method contains several base calls, the compiler gives a warning if this will result in duplicate base call invocations on all paths (definitely duplicate) or on some paths (potentially duplicate). Again super/tsuper calls are included in the flow analysis (see 4.3(b)).

(d) Parameter tunneling

If a base method has more parameters than a callin method to which it is composed, additional parameters are implicitly passed unchanged from the original call to the base call (original means: before interception). I.e., a call base.m() may invisibly pass additional parameters that were provided by the caller, but are hidden from the role method.

(e) Fragile callin binding

If a role method returns void, but the bound base method declares a non-void result, this is reported as a fragile callin binding: The result can still be provided by the base call, but omitting the base call may cause problems depending on the return type:

  • For reference return types null will be returned in this case.
  • In the case of primitive return types this will cause a ResultNotProvidedException at run-time.

It is an error if a callin method involved in a fragile callin binding has definitely no base call.

(f) Base super calls

If a callin method rm is bound to a base method B1.m that in turn overrides an inherited method B0.m (B0 is a super class of B1), the callin method may use a special form of a base call denoted as

base.super.rm();

Such base super call invokes the super method of the bound base method, here B0.m. This invocation is not affected by any further callin binding.

A base super call bypasses both the original method B1.m and also other callin bindings that would be triggered by a regular base call. For this reason any application of this construct is flagged by a decapsulation warning (see §3.4).

Comment:
Base calls can occur in callin methods that are not yet bound. These methods have no idea of the names of base methods that a sub-role will bind to them. Also multiple base methods may be bound to the same callin method. Hence the use of the role method's own name and signature. The language implementation translates the method name and signature back to the base method that has originally been invoked.
Example code (Base Call):
1
public class ValidatorRole playedBy Point {
2
  callin void checkCoordinate(int value) {
3
    if (value < 0)
4
      base.checkCoordinate(-value);
5
    else
6
      base.checkCoordinate(value);
7
  }
8
  checkCoordinate <- replace setX, setY;
9
}
Effects:
  • Line 2 defines a callin method which is bound to two methods of the base class Point (see line 8).
  • The value passed to either setX or setY is checked if it is positive (line 3).
  • Lines 4 and 6 show calls of the original method (base calls). While line 6 passes the original value, in the negative case (line 4) the passed value is made positive.

§4.4 Callin parameter mapping↑ §4

(a) General case parameter mapping

The rules for mapping callin parameters and result type are mainly the same as for callout bindings (§3.2) except for reversing the -> and <- tokens and swapping left hand side and right hand side.
Callin bindings using before have no result mapping. For result in after callin bindings see §4.4.(c) below.

(b) Restrictions for callin replace bindings

The right-hand side of a parameter mapping may either be the simple name of a base method argument without further computation, or an arbitrary expression not containing any base method argument.
Each base method argument must either appear as a simple name in exactly one parameter mapping or not be mapped at all. In the latter case, the original argument is "tunneled" to the base call, meaning, the callin method does not see the argument, but it is passed to the base method as expected.
If the base method declares a result, then

  • if the role method also declares a result, result must be mapped to itself:
    result -> result
  • if the role method does not declare a result, an arbitrary expression may be mapped to result:
    expression -> result
    If in this situation no result mapping exists, the result of the base call is "tunneled" and passed to the original caller (see fragile callin binding (§4.3.(e)) above).

These rules ensure that these bindings are reversible for the sake of base calls (§4.3).

As stated above a fragile callin binding (§4.3.(e)) is not allowed with a callin method that definitely has no base call (§4.3.(b)). A callin replace binding is not fragile if it provides the base result using a result mapping.

A callin method bound with replace to a base method returning void must not declare a non-void result.

(c) Mapping the result of a base method

In an after callin binding, the right-hand side of a parameter mapping may use the identifier result to refer to the result of the base method.

An after callin binding can, however, not influence the result of the base method, thus mappings with the -> token are not allowed for after callin bindings. For before mappings using the -> token is already ruled out by §4.4.(a)

(d) Multiple base methods

A callin binding listing more than one base method may use parameter mappings with only the following restriction: if any base parameter should be mapped this parameter must have the same name and type in all listed base method designators. However, different parameter mappings for different base methods bound to the same role method can be defined if separate callin bindings are used.

§4.5 Lifting and lowering↑ §4

For basic definition see §2.2 and §2.3.
(The following rules are reverse forms of those from §3.3)

(a) Call target translation

Invoking a role method due to a callin binding first lifts the base object to the role class of the callin binding, in order to obtain the effective call target. This is why callin bindings cannot be defined in roles that are unliftable due to potential binding ambiguity (see §4.1.(b) above and §2.3.4.(a)).

(b) Parameter translation

During callin execution, each parameter for which the role method expects a role object is implicitly lifted to the declared role class.

(c) Result translation

Returning a role object from a callin method implicitly lowers this object.

(d) Typing rules

A parameter mapping (implicit by parameter position or explicit by a with clause) is well typed if the right hand side conforms to the left hand side, either by

  • type equality
  • implicit primitive type conversion
  • subtype polymorphism
  • translation polymorphism, here: lifting;
    however, within replace bindings step 1 of the smart lifting algorithm (§2.3.3.(a)) is not applicable
  • or by a combination of the above.

A result mapping (implicit or explicit by a with clause) is well typed, if the value at the left hand conforms to the right hand side according to the rules given above, except that translation polymorphism here applies lowering instead of lifting.

These rules define translation polymorphism as introduced in §2.3.

Additionally, in a replace callin binding compatibility of parameters and return types must hold in both directions. Thus, from the above list of conversions a replace binding cannot apply subtype polymorphism nor primitive type conversion. If more flexibility is desired, type parameters can be used as defined in §4.10.

(e) Role arrays

For arrays of roles as parameters §2.3.(d) applies accordingly. For arrays as return value §2.2.(e) applies.

(f) Base calls

For base calls these rules are reversed again, i.e., a base call behaves like a callout binding.

§4.6 Overriding access restrictions↑ §4

Callin bindings may also mention inaccessible methods (cf. decapsulation §3.4). Due to the reverse call direction this is relevant only for base calls within callin methods. Base calls have unrestricted access to protected base methods. Accessing a base method with private or default visibility is also allowed, but signaled by a compiler warning.

Comment:
A base call to an inaccessible base method is considered harmless, since this is the originally intended method execution.

(a) Private methods from super classes

(Cf. §3.4.(d)) If a callin binding shall bind to a private base method, that method must be defined in the exact base class to which the current role class is bound using playedBy.
If a private base feature must indeed be callin-bound, a role class must be defined that is played by the exact base class defining the private feature. Another role bound to a sub-base-class can then be defined as a sub class of the first role. It will inherit the callin binding and through this it can access the desired feature.

§4.7 Callin binding with static methods↑ §4

The normal case of callin bindings refers to non-static methods on both sides (base and role). Furthermore, in Java inner classes can not define static methods. Both restrictions are relaxed by the following rules:

(a) Static role methods

A role class may define static methods (see also §1.2.1.(f)).

(b) Binding static to static

A callin binding may bind a static role method to one or more static base methods. It is, however, an error to bind a static base method to a non-static role method, because such binding would require to lift a base object that is not provided.

(c) before/after

In addition to the above, before and after callin bindings may also bind a static role method to non-static base methods.

(d) replace

In contrast to §4.7.(c) above, a replace callin binding cannot bind a static role method to a non-static base method.

The following table summarizes the combinations defined above:

<-   base method
static non-static
role
method
static OK before/after: OK
replace: illegal
non-static illegal OK

(e) No overriding

Since static methods are not dynamically bound, overriding does not apply in the normal semantics. Regarding callin bindings this has the following consequences (assuming a role RMid played by BMid plus its super-class BSuper and its sub-class BSub.

  1. If a static base method BMid.m is bound by a callin binding this has no effect on any method m in BSub.
  2. If a callin binding mentions a method m which is not present in BMid but resolves to a static method in BSuper the binding only affects invocations as BMid.m() but not BSuper.m(). If the latter call should be affected, too, the callin binding must appear in a role class bound to BSuper, not BMid.
  3. In order to bind two static base methods with equal signatures, one being defined in a sub-class of the other one, two roles have to be defined where one role refines the playedBy clause of the other role (say: public class RSub extends RMid playedBy BSub). Now each role may bind to the static base method accessible in its direct base-class.

§4.8 Callin precedence↑ §4

If multiple callins from the same team refer to the same base method and also have the same callin modifier (before, after or replace), the order in which the callin bindings shall be triggered has to be declared using a precedence declaration.

(a) Precedence declaration

A precedence declaration consists of the keyword precedence followed by a list of names referring to callin bindings (see §4.1.(e) for named callin bindings).

precedence callinBinding1, callinBinding2;

A precedence declaration is only legal within a role or team class.
The order of elements in a precedence declaration determines their priority during dispatch, similar to priorities based on activation of several team instances (§5.1). This means that before and replace binding with highest priority trigger first, whereas after bindings with highest priority trigger last. For binding precedences (as opposed to class based precedence, see §4.8.(c) below) which refer to after bindings, the precedence declaration must also use the after keyword to remind the programmer that the execution order is inverse to the textual order.

precedence after importantExecuteLast, lessImportantExecuteEarlier;

(b) Qualified and unqualified names

Within a role class a callin binding may be referenced by its unqualified name. A precedence declaration in a team class must qualify the callin name with the name of the declaring role class. A team with nested teams may concat role class names. Elements of a qualified callin name are separated by ".".
The callin binding must be found in the role specified by the qualifying prefix or in the enclosing role for unqualified names, or any super class of this role (including implicit super classes §1.3.1).

(c) Class based precedence

At the team level a precedence declaration may contain role class names without explicitly mentioning callin bindings in order to refer to all callin bindings of the role.

(d) Multiple precedence statements

All precedence statements are collected at the outer-most team. At that level all precedence declarations involving the same base method are merged using the C3 algorithm [3]. When merging precendence declarations more deeply nested declarations have higher priority than outer declarations. For several declarations at the same nesting level the lexical ordering determines the priority.

At any point the C3 algorithm will ensure that the resulting order after merging is consistent with each individual precedence declaration. It is an error to declare incompatible precedence lists that cannot be merged by the C3 algorithm.

(e) Binding overriding

Precedence declarations may conflict with overriding of callin bindings (see §4.1.(e)): For each pair of callin bindings of which one callin binding overrides the other one, precedence declarations are not applicable, since dynamic binding will already select exactly one callin binding.
It is an error to explicitly mention such a pair of overriding callin bindings in a precedence declaration.
When a class-based precedence declaration implicitly refers to a callin binding that is overridden by, or overrides any other callin binding within the same precedence declaration, this does not affect the fact, that the most specific callin binding overrides less specific ones.

Callin binding example
1
public class LogLogin playedBy Database {
2
  callin void log (String what) {
3
    System.out.println("enter " + what);
4
    base.log(what.toLowerCase());
5
    System.out.println("leave " + what);
6
  }
7
  void log(String what) <- replace void login(String uid, String passwd) 
8
    with { what <- uid }
9
}
10
(new Database()).login("Admin", "Passwd");
Effects:

Provided the callin bindings are active (cf. §5) then:

  • the call in line 10 is intercepted by method log of role LogLogin.
  • the call target of log is a role of type LogLogin which is created by lifting the original call target (of type Database) to LogLogin.
  • only parameter uid is passed to log (bound to formal parameter what).
  • within method log the base call (line 4) invokes the original method passing a modified uid (converted to lower case, cf. line 4) and the unmodified password, which is hidden from the callin method due to the parameter mapping in line 8.

§4.9 Callin inheritance↑ §4

This section defines how callin bindings and callin methods relate to inheritance.

§4.9.1 Base side inheritance↑ §4.9

Generally, a callin binding affects all sub-types of its bound base. Specifically, if a role type R bound to a base type B defines a callin binding rm <- callin_modifier bm, the following rules apply:

(a) Effect on sub-classes

The callin binding also effects instances of any type BSub that is a sub-type of B. If BSub overrides the bound base method bm, the overridden version is generally affected, too. However, if bm covariantly redefines the return type from its super version, the callin binding has to explicitly specify if the covariant sub-class version should be affected, too (see §4.9.3.(b)).

(b) No effect on super-classes

The binding never affects an instance of any super-type of B even if the method bm is inherited from a super-class or overrides an inherited method. This ensures that dispatching to a role method due to a callin binding always provides a base instance that has at least the type declared in the role's playedBy clause.

For corresponding definitions regarding static methods see §4.7.(e).

§4.9.2 Role side inheritance↑ §4.9

Any sub-type of R inherits the given callin binding (for overriding of bindings see §4.8.(e)). If the sub-role overrides the role method rm this will be considered for dynamic dispatch when the callin binding is triggered.

§4.9.3 Covariant return types↑ §4.9

Since version 5, Java supports the covariant redefinition of a method's return type (see JLS 8.4.5). This is not supported for callin methods (§4.9.3.(a)). If base methods with covariant redefinition of the return type are to be bound by a callin binding the subsequent rules ensure that type safety is preserved. Two constraints have to be considered:

  1. When a callin method issues a base-call or calls its tsuper version, this call must produce a value whose type is compatible to the enclosing method's declared return type.
  2. If a replace-bound role method returns a value that is not the result of a base-call, it must be ensured that the return value actually satisfies the declared signature of the bound base method.

(a) No covariant callin methods

A method declared with the callin modifier that overrides an inherited method must not redefine the return type with respect to the inherited method. This reflects that fact that an inherited callin binding should remain type-safe while binding to the new, overriding role method. Binding a covariant role method to the original base method would break constraint (1) above.

(b) Capturing covariant base methods

If a callin binding should indeed affect not only the specified base method but also overriding versions which covariantly redefine the return type, the binding must specify the base method's return type with a "+" appended to the type name as in

void rm() <- before RT+ bm();

Without the "+" sign the binding would only capture base methods whose return type is exactly RT; by appending "+" also sub-types of RT are accepted as the declared return type.

(c) Covariant replace binding

When using the syntax of §4.9.3.(b) to capture base methods with covariant return types in a callin binding with the replace modifier, the role method must be specified using a free type parameter as follows:

<E extends RT> E rm() <- replace RT+ bm();

The role method rm referenced by this callin binding must use the same style of return type using a type parameter. The only possible non-null value of type E to be returned from such method is the value provided by a base-call or a tsuper-call.
This rule enforces the constraint (2) above.
Note that this rule is further generalized in §4.10.

Binding a parametric role method
1
public class SuperBase {
2
    SuperBase foo() { return this; }
3
    void check() { System.out.print("OK"); }
4
}
5
public class SubBase extends SuperBase {
6
    @Override
7
    SubBase foo() { return this; }
8
    void print() { System.out.print("SubBase"); }
9
    String test() { 
10
        this.foo().print(); // print() requires a SubBase
11
    }
12
}
13
14
public team class MyTeam {
15
    protected class R playedBy SuperBase {
16
        callin <E extends SuperBase> E ci() {
17
			E result= base.ci();
18
			result.check(); // check() is available on E via type bound SuperBase
19
			return result;
20
        }
21
        <E extends SuperBase> E  ci() <- replace SuperBase+ foo();
22
    }
23
}
Explanation:
  • Method SubBase.foo in line 7 redefines the return type from SuperBase (inherited version) to SubBase, thus clients like the method call in line 10 must be safe to assume that the return value will always conform to SubBase.
  • The callin binding in line 21 explicitly captures both versions of foo by specifying SuperBase+ as the expected return type. Thus, if an instance of MyTeam is active at the method call in line 10, this call to foo will indeed be intercepted even though this call is statically known to return a value of type SubBase.
  • The callin method in lines 16-20 has a return type which is not known statically, but the return type is represented by the type variable E. Since the base call is known to have the exact same signature as its enclosing method, the value provided by the base call is of the same type E and thus can be safely returned from ci. Note, that no other non-null value is known to have the type E.
  • By specifying SuperBase as an upper bound for the type E the callin method ci may invoke any method declared in type SuperBase on any value of type E. For an example see the call to check in line 18.

As an aside note that the above example uses type SuperBase in an undisciplined way: within role R this type is bound using playedBy and the same type is also used directly (as the upper bound for E). This is considered bad style and it is prohibited if SuperBase is imported using an base import (§2.1.2.(d)). Here this rule is neglegted just for the purpose of keeping the example small.

§4.10 Generic callin bindings↑ §4

As mentioned in §4.5.(d) replace bindings do not support subtype polymorphism in either direction. On the other hand, binding several base methods to the same callin method may require some more flexibility if these base methods have different signatures. This is where type parameter come to the rescue to allow for generic callin methods and their binding to base methods with different signatures.
Note that this rule is a generalization of rule §4.9.3.(c).

Additionally, any callin binding (before,replace,after) may declare one or more type parameters for propagating type parameters of the bound base method(s) (§4.10.(e)).

(a) Fresh type parameter

If a callin method declares a type parameter <T> for capturing a covariant return type this type T can be used for specifying the type of exactly one parameter or the return type. If a type parameter is used in more than one position of a callin method it is not considered a fresh type parameter and can thus not be bound to a covariant return type (see §4.10.(d)).

(b) Type bounds

The type parameter of a callin binding may be bounded by an upper bound as in <T extends C>. In this case T can only be instantiated by types conforming to the upper bound C.

(c) Generic replace binding

A generic callin method according to the above rules is bound using a replace binding that declares the same number of type parameters, where type parameters of the binding and its callin method are identified. If the callin method declares bounds for its type parameters so should the replace binding.

(d) Binding to a type parameter

A fresh type parameter can be used to capture arbitrary types in the base methods to be bound. The type parameter may be instantiated differently for each bound base method. By such type parameter instantiation the types in role and base signatures are actually identical, thus satisfying the requirement of two-way substitutability.

Within the body of a generic callin method no further rules have to be followed, because the fresh type variable actually guarantees, that the role method cannot replace the original value (initial argument or base-call result) with a different object, because no type exists that is guaranteed to conform to the type parameters. Yet, the type bound allows the role method to invoke methods of the provided object.

Generic replace binding
1
public team class MyTeam {
2
    protected class R playedBy Figures {
3
        callin <E extends Shape, F extends Shape> E ci(F arg) {
4
            E result= base.ci(arg);
5
            result= arg; // illegal, types E and F are incommensurable
6
            arg= result; // illegal, types E and F are incommensurable
7
            int size= arg.getSize(); // getSize() is availabel on F via type bound Shape
8
            result.resize(size);     // resize() is available on E via type bound Shape
9
            return result; // only two legal values exist: result and null
10
        }
11
        <E extends Shape, F extends Shape> 
12
        E  ci(F arg) <- replace Rectangle getBoundingBox(Shape original), 
13
                                Rectangle stretch(Square original);
14
    }
15
}
Explanation:
These declaration generate two version of the callin method ci:
  1. Rectangle ci (Shape arg)
  2. Rectangle ci (Square arg)
Within the callin method the following observations hold:
  • Line 5 is illegal for the first signature as Shape is not conform to Rectangle
  • Line 6 is illegal for the second signature as Rectangle is not conform to Square
  • Everything else is type-safe.

(e) Propagating type parameters

If a callin binding binds to a generic base method, any type parameter(s) of the base method must be propagated into the role method by declaring the callin binding with type parameters, too. By matching a type parameter of a base method with a type variable of the callin binding, this genericity is propagated through the callin binding.

1
class MyBase {
2
	<T> T getIt(T it) { return it; }
3
}
4
team class MyTeam {
5
	protected class MyRole playedBy MyBase {
6
		callin <U> U rm(U a) { return base.rm(a); }
7
		<U> U rm(U a) <- replace U getIt(U it);
8
	}
9
}
Explanation:
The callin binding declares a type parameter <U> which is used to match all occurrences of T in the signature of getIt. Thus the implementation of rm uses the type U in exactly the same generic way as getIt uses T.

Open issues:↑ §4

The query language for specifying sets of base methods (§4.1.(d)) has not been finalized yet. In this version of the OTJLD §8 acts as a placeholder for the section that will define a join point query language in the future.

References:↑ §4

[3] Kim Barrett, Bob Cassels, Paul Haahr, David A. Moon, Keith Playford, P. Tucker Withington. A monotonic superclass linearization for Dylan. OOPSLA '96: Proceedings of the 11th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 69-82, 1996.