### §1.2.3 Protected roles

Roles can only be `public` or `protected`. A `protected` role is encapsulated by its enclosing team instance. This is enforced by these rules:

#### (a) Importing role classes

This rule is superseded by §1.2.2.(i)

#### (b) Qualified role types

The name of a `protected` role class may never be used qualified, neither prefixed by its enclosing type nor parameterized by a variable as type anchor (cf. §1.2.2.(a)).

#### (c) Mixing qualified and unqualified types

An externalized role type is never compatible to an unqualified role type, except for the substitutions in §1.2.2.(f), where an explicit anchor can be matched with the implicit anchor `this`.

Rules (a) and (b) ensure that the name of a protected role class cannot be used outside the lexical scope of its enclosing team. Rule (c) ensures that team methods containing unqualified role types in their signature cannot be invoked on a team other than the current team. Accordingly, for role methods the team context must be the enclosing team instance.

#### (d) Levels of encapsulation

Since protected role types can not be used for externalization, instances of these types are already quite effectively encapsulated by their enclosing team. Based on this concept, encapsulation for protected roles can be made even stricter by the rules of role confinement. On the contrary, even protected roles can be externalized as opaque roles which still expose (almost) no information. Confinement and opaque roles are subject of §7.