§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.