<< §2.3.(d) Lifting of arrays | ↑ Table of Contents ↑ | §2.3.2 Declared lifting >> |
§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:
- the given base object
- the given team object
- 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.
(d) Fine-tuning role instantiation
If the lifting operation as defined above degrades the program performance, the lifting semantics can be modified per role
class
by adding the annotation @org.objectteams.Instantiation
which requires an argument of type
org.objectteams.InstantiationPolicy
in order to select between the following behaviors:
- ONDEMAND
- This is the default behavior as defined above.
- ALWAYS
- This strategy avoids maintaining the internal role cache, but instead a fresh role instance is created for each lifting request.
This may increase the number of role instances but cuts the costs of accessing the cache, which could otherwise become
expensive if a cache grows large. As a result of this strategy role state can no longer be shared
over time, thus it is discouraged to define fields in a role with this strategy. Also, comparing roles could lead
to
unexpected results. Therefor, roles with this strategy should implement custom
equals
andhashCode
methods, which should simply delegate to the base instance (using callout §3). - NEVER
- Roles with this instantiation policy are never instantiated by lifting.
Such roles cannot define non-static fields.
Otherwise this optimization is fully transparent, specifically callout bindings will refer to the correct base instance.
As of version 2.0 the OT/J compiler does not implement this strategy. - SINGLETON
- Roles declaring this strategy will be instantiated at most once per team. Subsequent lifting requests in the same team
will always answer the same role instance. Such roles may receive triggers from callin bindings, but cannot define
callout bindings.
As of version 2.0 the OT/J compiler does not implement this strategy.
<< §2.3.(d) Lifting of arrays | ↑ Table of Contents ↑ | §2.3.2 Declared lifting >> |