Re: Java Feature Proposal
From: Adam Jenkins (adam_at_remove.thejenkins.me.org)
Date: 02/10/04
- Next message: Markus Brosch: "Re: unique identifier for an object?"
- Previous message: Gregory A. Swarthout: "Re: How to enable Java plug-in in Redhat Linux?"
- In reply to: christopher diggins: "Re: Java Feature Proposal"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 10 Feb 2004 14:15:47 -0500
christopher diggins wrote:
> "Adam Jenkins" <adam@remove.thejenkins.me.org> wrote in message
> news:4022703A.4010502@remove.thejenkins.me.org...
>
>>christopher diggins wrote:
>>>There is a more concrete example at
>>>http://www.heron-language.com/extensions.html . The patterns you mention
>>>have little, if anything, to do with what I am proposing.
>>
>>Ok, I just read that. As far as I can tell, your
>>interfaces-with-extensions are exactly equivalent to abstract classes
>>with a special restriction on the definition of the non-abstract
>>methods, namely that the definitions may only call methods of the class
>>they're defined in. By playing semantic games you're calling these
>>"interfaces" instead of "abstract classes", thereby allowing you to add
>>multiple-inheritance to Java without calling it that.
>>
>>Your extra restriction does not get rid of any of the problems with
>>multiple inheritance. For instance:
>>
>>interface ISomeInterface1 {
>> contract void Foo();
>> extension void DoSomething() { Foo(); }
>>}
>>
>>interface ISomeInterface2 {
>> contract void Bar();
>> extension void DoSomething() { Bar(); }
>>}
>>
>>class SomeClass implements ISomeInterface1, ISomeInterface2
>>{
>> public void Foo() { System.out.println("Foo()"); }
>> public void Bar() { System.out.println("Bar()"); }
>>
>> public static void main(String[] args) {
>> SomeClass instance = new SomeClass();
>> instance.DoSomething();
>> }
>>}
>>
>>What will this program print when run? Which implementation of
>>DoSomething() will be called? It was precisely to avoid these kinds of
>>ambiguities, and the complex rules needed to deal with them, that
>>multiple-inheritance was left out of Java.
>
>
> I responded previously to Anton Spaans with regards to this issues, you need
> simply cast to the appropriate interface in order to resolve the naming
> conflict (just as you would with any interface naming conflict). This is not
> a complicated rule. The extensions proposal does not introduce any new
> problems that do not already occur with naming conflicts with multiple
> implementation of interfaces.
No, there is no naming conflict with Java interfaces, since they contain
no implementations. In the current Java spec, it's not possible for a
class to inherit multiple conflicting implementations of a method. It's
only when the "interface" can contain methods with implementations, that
the need to resolve any conflict arises. So your proposal does in fact
introduce a new set of conflicts that need to be explicitly resolved.
Here's an example of what I mean:
interface ISomeInterface1 {
void foo();
}
interface ISomeInterface2 {
void foo();
}
class SomeClass implements ISomeInterface1, ISomeInterface2 {
public void foo() { System.out.println("foo()"); }
public static void main(String[] args) {
SomeClass instance = new SomeClass();
instance.foo();
}
}
In this case, it's just an academic question to ask whether
ISomeInterface1.foo() or ISomeInterface2.foo() is called, since there's
no implementation of either. The actual method implementation being
called is SomeClass.foo(), so there's no reason to cast "instance" to
ISomeInterface1 or ISomeInterface2.
Also, the fact that there is a way to manually resolve the conflict in
your proposal doesn't remove the need for language rules to handle the
cases where you don't manually disambiguate the call. And yes, I
already know it's possible to come up with the rules; I used C++ for
years before I learned Java so I'm quite familiar with multiple
inheritance, and I think I have some understanding of its pros and cons.
> Interfaces with extensions do not have fields, so there is no chance of
> multiple inheritance of fields which was the only big problem of [poorly
> used] MI.
I don't see why multiple inheritance of fields is any more of a problem
than multiple inheritance of methods; they seem to be about equivalent
problems to me, with similar solutions.
>>Other than the fact that they can't be multiply inherited, abstract
>>classes can provide the same functionality as you're proposing. Just
>>consider the abstract methods to be the contract, and the non-abstract
>>methods to be the extensions.
>
>
> Yes abstract base classes could be used similarly except that you can't have
> multiple inheritance of ABC's, and an abstract class can have fields. An
> abstract base class can also partially implement the contract of another
> abstract base class.
>
> I also wish to point out that by your argument all interfaces in general can
> be replaced entirely by abstract base classes.
But I'm not the one suggesting making it possible to have method
implementations in interfaces, you are. I think that the most important
difference between abstract classes and interfaces is that interfaces
cannot contain method implementations, which allows them to be multiply
inherited without introducing most of the problems of MI. I think that
*your* proposal is the one that makes interfaces similar enough to
abstract classes that you could just use abstract classes instead. I
don't see any really substantial differences between your proposed
interfaces and current Java abstract classes, except that your
"interfaces" can be multiply inherited. The other differences seem
minor in comparison.
Adam
- Next message: Markus Brosch: "Re: unique identifier for an object?"
- Previous message: Gregory A. Swarthout: "Re: How to enable Java plug-in in Redhat Linux?"
- In reply to: christopher diggins: "Re: Java Feature Proposal"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
