Sharing constraints Sample Clauses

Sharing constraints. Sharing relationships between types are not always preserved by derived families, either by design or as the result of changed class hierarchy in the derived family. For example, in a family inherited from ASTDisplay, one might choose not to share any class, or to share classes from TreeDisplay, and in either case, the new family no longer shares classes with the AST family. Therefore, a view-change operation that works in the base fam- ily might not make sense in the derived family. J&s does not try to check all inherited method code for inapplicable view changes, but rather makes checking modular via sharing constraints. A J&s method can have sharing constraints of the form sharing T1 = T2, which means that any value of type T1 can be viewed as of type T2, and vice versa; in other words, the sharing relationship T1 T2 may be assumed in the method body. A view change can only ap- pear in a method with an enabling sharing constraint. Outside the scope of sharing constraints, the type checker (and programmer) need not be concerned with sharing. Therefore, reasoning about class sharing is local. For example, in Figure 3, the method show has a shar- ing constraint AST!.Exp = Exp (line 6), which allows the view change (view Exp)e to be applied to the variable e of static type AST!.Exp. To know statically that the view change (view Exp)e will suc- ceed, we must know that every subclass of AST!.Exp has a corre- sponding shared subclass under ASTDisplay!.Exp. J&s requires that some prefix of each type in the constraint is exact, and either non-dependent or only dependent on the path this; thus, we can check all the subclasses in a locally closed world (Section 2.1), without a whole-program analysis. In this example, the exact pre- fixes in question are AST! and ASTDisplay[this.class]. The type checker verifies that sharing constraints in the base family still hold in the derived family; base family methods whose sharing constraints do not hold must be overridden. Although sharing constraints support modular type checking, they do introduce an annotation burden for the programmer. Our ex- perience suggests that the annotation burden is manageable. While it appears possible to automatically infer sharing constraints, by in- specting the type of the source expression and the target type of every view change operation in the method body, we leave this to future work.