<< §1.2.2 Externalized roles | ↑ Table of Contents ↑ | §1.2.4 Type tests and casts >> |
§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.
<< §1.2.2 Externalized roles | ↑ Table of Contents ↑ | §1.2.4 Type tests and casts >> |