<< §2.5 Abstract Roles | ↑ Table of Contents ↑ | §2.7 Advanced structures >> |
§2.6 Explicit base references
The role-base link is not meant to be accessed explicitly from programs,
but it is fully under the control of compiler and runtime environment.
Accessing features of a role's base object is done by
callout bindings (§3).
Yet, a keyword base
exists, which can be used in the following
contexts:
(a) Externalized roles of a base team
If the base class of a role T1.R1
is again a team
T2
, roles of that team T2
can be
externalized (see §1.2.2)
using base
as their type anchor. Given that
R2
is a role of T2
, one could write:
1 | public team class T1 { |
2 | protected class R1 playedBy T2 { |
3 | protected R2<@base> aRoleOfMyBase; |
4 | } |
5 | } |
This syntax is only legal within the body of the role T1.R1
which is bound
to the team T2
containing role R2
.
A static type prefix can be used to disambiguate a base anchor, so the explicit variant
of the above type would be R2<@R1.base>
.
It is not legal to use a type anchor containing base
as an element in a path
of references like <@base.field>
or <@field.base>
.
(b) Explicit base object creation
Within a role constructor (which is not the lifting constructor)
the syntax base(arguments)
causes an instance
of the bound base class to be created and linked (see §2.4.2).
(c) Base call in callin method
Within a callin method (§4.2.(d))
an expression base.m(args)
is used to invoke the
originally called method (see §4.3).
(d) Base guard predicates
Guard predicates (§5.4) can
be specified to act on the base side using the base when
keywords.
Within such a base guard predicate base
is interpreted as a special identifier
holding a reference to the base object that is about to be lifted
for the sake of a callin method interception (see §5.4.2.(a)).
(e) Parameter mappings
An expression at the right-hand side of a parameter mapping
(parameter in a callin binding (§4.4) or
result in a callout binding (§3.2.(c)) ) may use the keyword base
to refer to the bound base instance. Such usage requires the role method bound in this method binding to be non-static.
(f) Inhibition of modification
In all cases, the base
reference is immutable,
i.e., base
can never appear as the left-hand-side of an assignment.
(g) Decapsulation via base reference
In cases §2.6.(d) and §2.6.(e) above, members of the base
object may be accessed that would not be visible under Java's visibility rules.
Such references are treated as decapsulation in accordance with §3.4.(a) and §3.5.(e).
Note that accessing a base field via base
only gives reading access to this field.
<< §2.5 Abstract Roles | ↑ Table of Contents ↑ | §2.7 Advanced structures >> |