next up previous
Next: 2.3.3.2 Built-in Delegation. Up: 2.3.3 Language support Previous: 2.3.3 Language support

  
2.3.3.1 similar

In order to ease the implementation of scenarios which require substitutability of child instances for parent instances let us first explore a new construct for class definition, called similar, with the following semantics:

class C similar D {...} declares that class C implements all the public methods in class D and that C instances may be used for D instances. This construct permits omission of explicit interface declaration for D (which was required in the earlier translation). However, code reuse still entails defining a D-type field in class C, and forwarding some method calls to it while redefining others.

This approach can lead to name conflicts and is therefore subject to the complications discussed earlier. Compare, for instance

class Clock extends Applet similar Thread { ... };
with the discussion of the Clock applet given earlier.

So, to simplify matters, it is tempting to require that the superclass of C and the classes similar to C have disjoint methods. However, the semantics of forwarding captured by these translations may not be appropriate as explained below.



T. K. Prasad