§2.4.3 Role creation in the presence of smart lifting
Explicitly instantiating a role R1 bound to a base B where smart lifting of B to R1 would actually
provide a subrole R2 is dangerous: Instantiation enters the R1 into the team's internal cache. If at any time later lifting
this B to R2 is requested, which is a legal request, the runtime system will answer by throwing a org.objectteams.WrongRoleException
because it finds the R1 instead of the required R2.
For this reason, in this specific situation the explicit instantiation new R1(..) will be flagged by a warning.
The problem can be avoided by using R2 in the instantiation expression.
Example code (WrongRoleException):
| 1 |
public class B { void bm() {} } |
| 2 |
public team class T { |
| 3 |
protected class R1 playedBy B {...} |
| 4 |
protected class R2 extends R1 { |
| 5 |
void rm() { } |
| 6 |
} |
| 7 |
public B getDecoratedB() { |
| 8 |
return new R1(new B()); |
| 9 |
} |
| 10 |
public void requestLifting(B as R2 r) {} |
| 11 |
} |
| 12 |
|
| 13 |
T t = new T(); |
| 14 |
B b = t.getDecoratedB(); |
| 15 |
t.requestLifting(b); |
Bto the lifting constructor ofR1(see §2.4.1.(b)). In order to return thisBinstance lowering is implicitly used for the return statement.btoR2is requested but due to line 8 anR1is found in the internal cache.