<< §1.2.1 Modifiers for roles | ↑ Table of Contents ↑ | §1.2.3 Protected roles >> |
§1.2.2 Externalized roles
Normally, a team encapsulates its role against unwanted access from the outside. If roles are visible outside their enclosing team instance we speak of externalized roles.
Externalized roles are subject to specific typing rules in order to ensure, that role instances from different team instances cannot be mixed in inconsistent ways. In the presence of implicit inheritance (§1.3.1) inconsistencies could otherwise occur, which lead to typing errors that could only be detected at run-time. Externalized roles use the theory of "virtual classes" [1], or more specifically "family polymorphism" [2], in order to achieve the desired type safety. These theories use special forms of dependent types. Externalized roles have types that depend on a team instance.
§1.2.3 deduces even stronger forms of encapsulation from the rules about externalized roles.
(b) Declaration with anchored type
Outside a team role types are legal only if denoted relative to an existing team instance (further on called "anchored types"). The syntax is:
final MyTeam myTeam = expression; RoleClass<@myTeam> role = expression;
The syntax Type<@anchor>
is a special case of a parameterized type, more specifically a value dependent type (§9).
The type argument (i.e., the expression after the at-sign) can be a simple name or a path. It must refer to an instance
of a team class.
The role type is said to be anchored to this team instance.
The type-part of this syntax (in front of the angle brackets) must be the simple name of a role type directly contained
in the given team (including roles that are acquired by implicit inheritance).
Note:
Previous versions of the OTJLD used a different syntax for anchored types, where the role type was prefixed with the anchor expression, separated by a dot (anchor.Type
,
see §A.6.3). A compiler may still support that path syntax but it should be flagged as being deprecated.
(c) Immutable anchor
Anchoring the type of an externalized role to a team instance
requires the team to be referenced by a variable which
is marked final
(i.e., immutable).
The type anchor can be a path v.f1.f2...
where
v
is any final variable and f1
...
are final fields.
(d) Implicit type anchors
The current team instance can be used as a default anchor for role types:
- In non-static team level methods role types are by default interpreted as anchored to
this
(referring to the team instance). I.e., the following two declarations express the same:public RoleX getRoleX (RoleY r) { stmts } public RoleX<@this> getRoleX (RoleY<@this> r) { stmts }
- In analogy, role methods use the enclosing team instance as the default anchor for any role types.
Note, that this
and Outer.this
are always
final
.
The compiler uses the pseudo identifier tthis
to denote
such implicit type anchors in error messages.
(e) Conformance
Conformance between
two types RoleX<@teamA>
and RoleY<@teamB>
not only requires the role types to be compatible, but also
the team instances to be provably the same object.
The compiler must be able to statically analyze anchor identity.
(f) Substitutions for type anchors
Only two substitutions are considered for determining team identity:
-
For type checking the application of team methods,
this
is substituted by the actual call target. For role methods a reference of the formOuter.this
is substituted by the enclosing instance of the call target. - Assignments from a
final
identifier to anotherfinal
identifier are transitively followed, i.e., ift1, t2
are final, after an assignmentt1=t2
the typesR<@t1>
andR<@t2>
are considered identical. OtherwiseR<@t1>
andR<@t2>
are incommensurable.
Attaching an actual parameter to a formal parameter in a method call is also considered as an assignment with respect to this rule.
(g) Legal contexts
Anchored types for externalized roles may be used in the following contexts:
- Declaration of an attribute
- Declaration of a local variable
- Declaration of a parameter or result type of a method or constructor
- In the
playedBy
clause of a role class (see §2.1).
It is not legal to inherit from an anchored type, since this would require membership of the referenced team instance, which can only be achieved by class nesting.
Note:
Item 4. — within the given restriction — admits the case where the same class is a role of one team and the base class for the role of another team. Another form of nesting is defined in §1.5.(h) Externalized creation
A role can be created as externalized using either of these equivalent forms:
outer.new Role() new Role<@outer>()
This requires the enclosing instance outer
to be
declared final
. The expression has the
type Role<@outer>
following the rules of
externalized roles.
The type Role
in this expression must be a simple
(unqualified) name.
(i) No import
It is neither useful nor legal to import a role type.
Rationale:
Importing a type allows to use the unqualified name in situations that would otherwise require to use the fully qualified name, i.e., the type prefixed with its containing package and enclosing class. Roles, however are contained in a team instance. Outside their team, role types can only be accessed using an anchored type which uses a team instance to qualify the role type. Relative to this team anchor, roles are always denoted using their simple name, which makes importing roles useless.A static import for a constant declared in a role is, however, legal.
Example code (Externalized Roles):
1 | team class FlightBonus extends Bonus { |
2 | public class Subscriber { |
3 | void clearCredits() { ... } |
4 | } |
5 | void unsubscribe(Subscriber subscr) { ... } |
6 | } |
7 | class ClearAction extends Action { |
8 | final FlightBonus context; |
9 | Subscriber<@context> subscriber; |
10 | ClearAction (final FlightBonus bonus, Subscriber<@bonus> subscr) { |
11 | context = bonus; // unique assignment to 'context' |
12 | subscriber = subscr; |
13 | } |
14 | void actionPerformed () { |
15 | subscriber.clearCredits(); |
16 | } |
17 | protected void finalize () { |
18 | context.unsubscribe(subscriber); |
19 | } |
20 | } |
<< §1.2.1 Modifiers for roles | ↑ Table of Contents ↑ | §1.2.3 Protected roles >> |
Effects:
Action
which is used to associate the action of resetting a subscriber's credits to a button or similar element in an application's GUI.context
(line 8) and parameterbonus
(line 10) serve as anchor for the type of externalized roles.subscriber
(line 9) and parametersubscr
(line 10) store a Subscriber role outside the FlightBonus team.final
and prior to the role assignment a team assignment has taken place (line 11).Note, that the Java rules for definite assignments to final variables ensure that exactly one assignment to a variable occurs prior to its use as type anchor. No further checks are needed.
clearCredits
(line 15). This method call is also an example for implicit team activation (§5.3.(b)).unsubscribe
is for this call expanded tocontext
forthis
). This proves identical types for actual and formal parameters.