Name: rmT116609 Date: 07/24/2003


DESCRIPTION OF THE REQUEST :

class Foo implements FooInf via foovar {
   FooInf foovar;

   ....
}

This would result in the compiler generating for each method in FooInf that
is not explicitly defined in class Foo, a method that will delegate the method
call to foovar.

For example:

public interface FooInf {
   public void setVar(int value);
   public intgetVar();
   public void increment(int value);
}

public class Foo implements FooInf via fooVar {
   FooInf fooVar;

   public void increment(int value) {
       // do something else with value
       ...
   }
}

would behave as if this is the source for class Foo
   

public class Foo implements FooInf via fooVar {
   FooInf fooVar;

   public void increment(int value) {
       // do something else with value
       ...
   }

   public void setVar(int value) {
       fooVar.setVar(value);
   }

   public int getVar() {
       return fooVar.getVar;
   }
}

Note that the name after the via must be a instance variable of the class that implements the same interface.

JUSTIFICATION :
This would sure save a lot of busy typing when using delegation to an
aggregate variable.

It effectively provides a multiple inheritance capability while keeping the
language semantics clean.

**It will solve a major problem with migrating sources to future versions of the JDK. Right now it is possible to write a class that cannot be compiled
in a future version of the JDK without hand editing, and if hand edited it
won't be compilable on the previous version.

Here's the case. If I create a wrapper class that wraps around another class
both of which implement some interface. If that interface changes by added more
methods, the wrapper class will not compile until hand edited to add the additional methods even though the additional methods are not of interest.

Example: In JDBC I want to create a class that wraps a Statement instance in
order to perform some logging of a couple of method calls. Thus for all other
methods a method must still be coded to delegate the call to the wrapped Statement instance. Note that the wrapper class must implement the Statement
interface in order to be used itself as a Statement interface. The problem is
that if the definition of the Statement interface is enhanced (as in the case
of JDBC 3.0 in the JDK 1.4 release) that wrapper class will no longer compile
since it will be missing the implementation of the added methods. However if
implements via was available, it would.
(Incident Review ID: 190889)
======================================================================