C
Casey Hawthorne
A Java "interface" declaration does not allow a constructor to be
specified in it -- has this been fixed in Java 1.5?
specified in it -- has this been fixed in Java 1.5?
A Java "interface" declaration does not allow a constructor to be
specified in it -- has this been fixed in Java 1.5?
Casey Hawthorne said:A Java "interface" declaration does not allow a constructor to be
specified in it -- has this been fixed in Java 1.5?
Casey Hawthorne said:A Java "interface" declaration does not allow a constructor to be
specified in it -- has this been fixed in Java 1.5?
Casey said:A Java "interface" declaration does not allow a constructor to be
specified in it -- has this been fixed in Java 1.5?
Casey said:A Java "interface" declaration does not allow a constructor to be
specified in it -- has this been fixed in Java 1.5?
Casey said:A Java "interface" declaration does not allow a constructor to be
specified in it -- has this been fixed in Java 1.5?
Lee Fesperman said:This suggested extension to Java has been discussed in the group before. At that time, I
objected to it because of the complications it incurred. My example was a class that
implemented such an interface and also extended another class. The constructor required
for the interface could make it impossible to call the constructor for the super class
because the interface constructor did not provide information required for the super
class constructor.
Your article prompted me to come up with another objection -- If two interfaces had
conflicting constructors, a sub class could not inherit both. This would be a more
onerous restriction than the current restriction on the two interfaces having methods
with the same signature and conflicting return types.
This brings me to wonder how you would handle a sub interface. Would it inherit the
constructor? Could it override a super constructor?
I think the real problem is that you're violating the spirit of interfaces. By
definition, they don't specify implementation. A constructor would tend to imply a
specific implementation.
xarax said: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.
Oscar kind said: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).
- 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.
=========================================
public class MailMan
extends Person [rename transport:transportBlah],
MailDelivery
{
public MailMan()
{
super
{
Person();
MailDelivery();
}
}
}
=========================================
xarax said:Both.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.