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