# §9 Value Dependent Classes

### Generalizing externalized roles

Type Value Parameter
In addition to regular generics, a class may declare parameters that represent an object value. Such a value parameter is called the type anchor for this class, the class's type is said to be anchored to this parameter.
Value Dependent Classes
A class that declares one or more value parameters depends on the runtime instance(s) denoted by its anchor(s).
Externalized Roles
The concept of externalized roles (§1.2.2) is a special case of the concepts presented here.

## §9.1 Defining classes with value parameters↑ §9

→ Syntax §A.9.1

#### (a) Value parameter declaration

Within the angle brackets that mark the parameters of a generic class also value parameters can be declared. In contrast to a type parameter, a value parameter is denoted as a pair of two identifiers: a type and a free name, e.g.,

    class MyClass<YourType aName> { ...

Note that value parameters are valid for classes only, not for interfaces.

#### (b) Value parameter application

Within the given class (`MyClass`) the parameter name (`aName`) can be used like a final field of the given type (`YourType`). In contrast to regular final fields the assignment to this name occurs even before the constructor is executed.

#### (c) Role types as dependent types

Any role type can be interpreted as a value dependent type, however, in the declaration of a role type the value parameter remains implicit: it is identical to the enclosing team instance.

## §9.2 Using classes with value parameters↑ §9

→ Syntax §A.9.2

When using a class which declares one or more value parameters (type anchors) a corresponding anchor value has to be provided.

### §9.2.1 Parameter substitution↑ §9.2

Substitution of a type anchor of a class `MyClass<YourType p>` is denoted as `MyClass<@v>`. In this term `v` must be a value which is conform to the declaration of the value parameter "`YourType p`", ie., `v` must have the static type `YourType`.
The value passed for substituting a type anchor must be a path of variables declared as `final`. Obviously, only the first element in such a path can be a local variable or a method argument, all other elements have to be fields. The reason for requiring final variables is in type checking as discussed next.

##### Note:

Externalized roles as defined in §1.2.2.(b) are a special case of types with a value parameter, where the value is an instance of the enclosing team.

#### (a) Instance constrained type parameters

In addition to normal usage, a value parameter can be applied nested to a regular type parameter:

    class MyClass<YourType aName, DependentParam<@aName>> { ...

Here the type parameter `DependentParam` is constrained to be anchored to `aName`.

If a value parameter is used as a constraint for a regular type parameter any substitution for the type parameter must also supply a value matching the value parameter. The class from above could be applied like this:

    final YourType anchor = new YourType();
    MyClass <@anchor, YourDependent<@anchor>>

Within the declaring element (class or method) applications of the type variable representing the instance constrained type parameter must repeat the anchor verbatim, i.e., no substitutions are performed here.

### §9.2.2 Type conformance↑ §9.2

Two value dependent types (anchored types) are considered conform only if the anchors of both types refer to the same object(s). The compiler must be able to statically analyze this anchor identity.

#### (a) Substitutions for type anchors

Only two substitutions are considered for determining anchor identity:

1. If a method signature uses `this` as the anchor of any of its types, type checking an application of this method performs the following substitutions:
   A simple `this` expression is substituted by the actual call target of the method application.
   A qualified `Outer.this` expression is substituted by the corresponding enclosing instance of the call target.
2. Assignments from a `final` identifier to another `final` identifier are transitively followed, i.e., if `t1, t2` are final, after an assignment `t1=t2` the types `C<@t1>` and `C<@t2>` are considered identical. Otherwise `C<@t1>` and `C<@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.

#### (b) Conformance of raw types

After anchors have been proven identical, the raw types are checked for compatibility using the standard Java rules.

## §9.3 Restrictions and limitations↑ §9

#### (a) No overriding

Types with value parameters that are declared outside a team cannot be overridden, as roles can be. Therefor, implicit inheritance does not apply for these types.

#### (b) Only first parameter

Currently only the first parameter of a class may be a value parameter. This restriction may be removed in the future.