#### §1.3.1.(e) Dynamic binding of types

Overriding an acquired role by a new role class has the following implication: If an expression or declaration, which is evaluated on behalf of an instance of team `T` or one of its contained roles, refers to a role `R`, `R` will always resolve to `T.R` even if `R` was introduced in a super-team of `T` and even if the specific line of code was inherited from a super-team or one of its roles. Only the dynamic type of the enclosing team-instance is used to determine the correct role class (see below for an example).

A special case of dynamically binding role types relates to so-called class literals (see JLS §15.8.2). Role class literals are covered in §6.1.(c).

The above is strictly needed only for cases involving implicit inheritance. It may, however, help intuition, to also consider the directly acquired role `T.R` in (b) to override the given role `S.R`.

In line 17 of Listing 1.3.1-1 the implicitly inherited method `n` is called with the result of an invocation of `m`. Although `n` was defined in `S` (thus with argument type `S.R2, see line 6`) in the context of `T` it expects an argument of `T.R2`. This is correctly provided by the invocation of `m` in the context of `T`.