Re: A Java "interface" declaration does not allow a constructor to be specified in it ...

From: xarax (xarax_at_email.com)
Date: 11/09/04 

Date: Tue, 09 Nov 2004 20:37:31 GMT

"Oscar kind" <oscar@danwa.net> wrote in message
news:rqd762-qbu.ln1@odin.asgard...
> xarax <xarax@email.com> wrote:
> >
> > If Java supported full multiple inheritance (which is
> > the implication of interface constructors), then there
> > would be no need for interfaces; just use abstract classes
> > in place of interfaces.
>
> Which poses other problems. Imagine the following (but please bear with
> the slightly off analogy):
>
> abstract class Person has a non-abstract method "transport", that
> implements walking.
>
> abstract class MailDelivery has a non-abstract method "transport", which
> implements mail delivery.
>
> class MailMan extends both, and thus inherits the method transport from both
> classes. For some reason, there is no reason to override it. Now please
> think about these questions:
> - Which one is inherited?

Both.

> - If one is chosen automatically, what about dependencies in another
> superclass? The two methods may have an incompatible contract.
n/a

> - If the method autometically becomes abstract, why? Abstract methods are
> always marked thus (either by the keyword abstract or by being defined
> in an interface).

Not abstract.

> - How do you select the transport method from Person? Extend the syntax
> again, with Person.super.transport()? It's hardly efficient to get a
> complicated, arcane syntax.

The child class is the one causing the name conflict.
Therefore there would be a facility to rename one of
the conflicting methods in one of the parent classes.

The Eiffel language has full multiple inheritance. When
a name conflict arises, it is the responsibility of the
inheriting class to resolve the conflict by renaming.
Otherwise, a compile-time error occurs. The renaming is
at the compile-time so that the compiler can distinguish
which parent method is getting called.

Extending the Java language to support full MI requires
such language extensions to specify which constructors
are called (with whatever appropriate parameters), the
order in which those constructors are called, and to
resolve the issue of name conflicts.

On the extends clause where the parents are specified
is likely where the renaming would occur through something
like:

=========================================
public class MailMan
extends Person [rename transport:transportBlah],
        MailDelivery
{
    public MailMan()
    {
        super
        {
            Person();
            MailDelivery();
        }
    }
}
=========================================

I used square brackets '[]', rather than braces '{}',
for the renaming to avoid parsing confusion with the
class body braces. The keyword "rename" is probably
not a good choice, as it is likely already in wide
use as a normal identifier.

Another issue arises with polymorphism when the
MailMan instance is up-cast to either Person or
MailDelivery, and subsequently the "transport"
method is called. If there was no redefinition,
then the non-renamed method would likely be called.

However, redefining a method in the subtype would
require specifying some kind of "preference" as to
which parent method is called.

IIRC, Eiffel uses the term "polymorphic catcalls"
for this situation and there are complicated rules
as to resolving the ambiguity.

In the current Java language, the last redefinition of
a method is the one that takes effect. Implementing
multiple interfaces with the same method signature can
lead to confusion. So, such situations are avoided when
practical (cannot rename inherited methods in Java).

There would also be issues involving the JVM and
the reflection libraries, which presume that an instance
has a linear chain of parents, and interfaces are treated
quite differently from classes.

Relevant Pages

  • Re: Java Feature Proposal
    ... > conflict. ... No, there is no naming conflict with Java interfaces, since they contain ... class to inherit multiple conflicting implementations of a method. ... I don't see why multiple inheritance of fields is any more of a problem ...
    (comp.lang.java.programmer)
  • Re: Need help: about OOP inheritance/abstract class
    ... but you can create a class that instantiates the user control in the ... >> constructor, or that inherits it, and inherit the interfaces. ...
    (microsoft.public.dotnet.general)
  • Re: Noun Oriented Thinking Considered Harmful
    ... IJumpingThing which TDog or one of its parent classes ... same for all its descendants, ... Using Interfaces, this situation is even more hopeless - since an Interface ...
    (borland.public.delphi.non-technical)
  • Re: Java "interface" vs. OO interface
    ... which isn't a statically typed language. ... the Nice language (which is build on top of Java) tries to "fix this ... bug" using "static interfaces", if I understand correctly. ... Seriously, if a class implements an interface, it obviously "inherits" all ...
    (comp.object)
  • Re: [PATCH] alternative to sys_indirect, part 1
    ... certainly doesn't use any of the new interfaces, yet if accept inherits ... the CLOEXEC flag from the socket, would visibly change existing programs. ...
    (Linux-Kernel)