§2.3.1 Implicit role creation

Lifting tries to reuse existing role objects so that role state persists across lifting and lowering. If no suitable role instance is found during lifting, a new role is created.

(a) Reuse of existing role objects

A role object is considered suitable for reuse during lifting, if these three items are identical:

  1. the given base object
  2. the given team object
  3. the statically required role type

For the relation between the statically required role type and the actual type of the role object see "smart lifting" (§2.3.3).

(b) Default lifting constructor

Lifting uses a default constructor which takes exactly one argument of the type of the declared base class (after playedBy). By default the compiler generates such a constructor for each bound role. On the other hand, default constructors that take no arguments (as in JLS §8.8.7) are never generated for bound roles.
The super-constructor to be invoked by a default lifting constructor depends on whether the role's super class is a bound role or not.

  • If the super-class is a bound role, the default lifting constructor will invoke the default lifting constructor of the super-class.
  • If the super-class is not a bound role, the default lifting constructor will invoke the normal argumentless default constructor of the super-class.

(c) Custom lifting constructor

If a role class declares a custom constructor with the same signature as the default lifting constructor, this constructor is used during lifting. This custom constructor may pre-assume that the role has been setup properly regarding its base-link and registered in the team's internal map of roles.
If a bound role has an unbound super-class without an argumentless constructor, providing a custom lifting constructor is obligatory, because no legal default lifting constructor can be generated.