§8. Join point queries   Table of  Contents

ObjectTeams/Java Language Definition - §9.

§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. The syntax will eventually be migrated to use value parameters only.

§9.1. Defining classes with value parameters

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 occurrs even before the constructor is executed.

§9.2. Using classes with value parameters

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

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: This syntax supercedes the paths defined in §1.2.2(b). Semantically both forms are equivalent, but the syntax presented here is more explicit and more versatile.

§9.2.2. Type conformance

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.
.. to be continued ..

§9.3. Limitations

Currently only the first parameter of a class may be a value parameter.

  §8. Join point queries   Table of  Contents
© Stephan Herrmann, Christine Hundt
OT/J Version 0.9 — Last modified: Wed Dec 20 2006