<< §2.1.2.(b) Cycles | ↑ Table of Contents ↑ | §2.1.2.(d) Base imports >> |
§2.1.2.(c) Base class decapsulation
If a base class referenced after playedBy
exists but is not visible under normal visibility rules of Java,
this restriction may be overridden. This concept is called decapsulation, i.e., the opposite of encapsulation
(see also §3.4). A compiler should signal any occurrence of base class decapsulation. If a compiler supports to
configure warnings this may be used to let the user choose to (a) ignore base class decapsulation, (b) treat it as a warning
or even
(c) treat it as an error.
Binding to a final
base class is also considered as decapsulation, since a playedBy
relationship has
powers similar to an extends
relationship, which is prohibited by marking a class as final
.
Decapsulation is not allowed if the base class is a confined role (see §7.2).
Within the current role a decapsulated base class can be mentioned in the right-hand-side of any method binding (callout (§3) or callin (§4)). Also arguments in these positions are allowed to mention the decapsulated base class:
- the first argument of one of the role's constructors (see lifting constructor (§2.4.1)).
- the base side of an argument with declared lifting (see declared lifting (§2.3.2)).
<< §2.1.2.(b) Cycles | ↑ Table of Contents ↑ | §2.1.2.(d) Base imports >> |