## §3.4 Overriding access restrictions

In contrast to normal access restrictions, method bindings may refer to hidden base methods. This concept is the inverse of encapsulation, hence it is called decapsulation.
Decapsulation may occur in these positions:

- `playedBy` declaration (see §2.1.2.(c))
- base constructor call (see §2.4.2.(b)).
- callout bindings (see next)
- callout to field (see §3.5.(e))
- base call within a callin method (see §4.6)

#### (a) Callout to inaccessible base method

By means of callout bindings it is possible to access methods of a base class regardless of their access modifiers. Method bindings are the only place in a program which may mention otherwise inaccessible methods. Access to the callout method at the role side is controlled by regular mechanisms, based on the declaration of the role method.

#### (b) Sealing against decapsulation

A base package may be "sealed" which re-establishes the standard Java visibility rules.
Sealing is achieved by the corresponding capability of Jar files.

#### (c) Warning levels

A compiler should signal any occurrence of 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 (cf. §2.1.2.(c)).
Optionally, a batch compiler may support three levels of verbosity with respect to decapsulation:

`-nodecapsulation` | No warnings.
default | Warn only if/that access restrictions are overridden.
`-decapsulation` | Detailed messages containing the binding and the hidden base method.

#### (d) Private methods from super classes

If a callout binding shall bind to a private base method, that method must be defined in the exact base class to which the current role class is bound using `playedBy`. I.e., for private methods §3.1.(d) does not hold.
The same holds for private base fields (see below).
If a private base feature must indeed be callout-bound, a role class must be defined that is played by the exact base class defining the private feature. Another role bound to a sub-base-class can then be defined as a sub class of the first role. It will inherit the callout binding and through this it can access the desired feature.

1

    public class SuperBase {

2

      private int secret;

3

    }

4

    public class SubBase extends SuperBase  { /* details omitted */ }

5

    public team class MyTeam {

6

      protected class SuperRole playedBy SuperBase {

7

        int steal() -> get int secret; // OK

8

      }

9

      protected class SubRole extends SuperRole playedBy SubBase {

10

        int steal() -> get int secret; // illegal!

11

      }

12

    }