<< §2.3.2 Declared lifting | ↑ Table of Contents ↑ | §2.3.4 Binding ambiguities >> |
§2.3.3 Smart lifting
In situations where role and base classes are part of some inheritance
hierarchies (extends
), choosing the appropriate role class during
lifting involves the following rules:
(a) Static adjustment
If a base class B
shall be lifted to a role class
R
that is not bound to (playedBy
)
B
, but if a subclass of R
— say R2
—
is bound to B
, lifting is statically setup to use
R2
, the most general subclass of R
that
is bound to B
or one of its super-types.
Restriction:
This step is not applicable for parameter mappings ofreplace
callin bindings (§4.5.(d)).
(b) Dynamic selection of a role class
At runtime also the dynamic type of a base object is considered:
Lifting always tries to use a role class that is bound to the
exact class of the base object. Lifting considers all role–base
pairs bound by playedBy
such that the role class is a
sub-class of the required (statically declared) role type
and the base class is a super-class of the
dynamic type of the base object.
From those possible pairs the most specific base class is chosen.
If multiple role classes are bound to this base class the most
specific of these classes is chosen.
(c) Team as closed world
In the above analysis gathering all role-base pairs is performed at
compile-time. From this follows, that a team class can only be
compiled when all its contained role classes are known and a role class
can never be compiled without its team.
The analysis includes all roles and their bindings that are inherited
from the super-team.
(d) Selection regardless of abstractness
Smart lifting is not affected by abstractness of role classes. For the effect of abstract role classes see §2.5.
Complex Example:
role class | base class |
---|---|
class R1 | |
class R2 extends R1 playedBy B2 | class B2 |
class R3 extends R2 /* inherited: playedBy B2 */ | class B3 extends B2 |
class R4 extends R3 playedBy B4 | class B4 extends B3 |
class R5 extends R4 /* inherited: playedBy B4 */ | |
class B6 extends B4 | |
class R7 extends R5 playedBy B7 | class B7 extends B6 |
If the inheritance hierarchies of the involved base and role classes are given (like in the figure above)
the smart lifting algorithm can be rephrased to the following "graphical" rule:
B6
in the example) move upwards the the inheritance
relation until you reach a base class bound to a role class indicated by a «playedBy»
arrow pointing to the base class (B4
). This role class must be conform to the requested role type.
Switch to the role side along this arrow (R4
). Now move downwards the role inheritance hierarchy
as long as the subrole does not refine the playedBy relationship (indicated by another «playedBy» arrow).
The bottom role you reach this way (R5
) is the role type selected by smart lifting.
<< §2.3.2 Declared lifting | ↑ Table of Contents ↑ | §2.3.4 Binding ambiguities >> |
B3
toR1
this is statically refined to useR2
instead, because this is the most general class declaring a binding to a super–class ofB3
.B6
, three steps select the appropriate role:playedBy
clauses (including those that are inherited) the following role–base pairs are candidates:(R2,B2), (R3,B2), (R4,B4)
and(R5,B4)
.B4
are chosen.R4
andR5
role candidates, from which the most specificR5
is finally chosen.