[1059] in java-interest
Re: Assertions in Java (& more)
daemon@ATHENA.MIT.EDU (John D. Mitchell)
Thu Aug 17 20:50:45 1995
Date: Thu, 17 Aug 1995 14:30:19 -0700
From: "John D. Mitchell" <johnm@CSUA.Berkeley.EDU>
To: anders@in.otc.com.au
CC: java-interest@java.sun.com
In-reply-to: <199508170633.AA09274@file.in.otc.com.au>
anders@in.otc.com.au writes:
> You hit on something that I've been trying to get my mind around for a
> while now. Why was it necessary to replace mutliple class inheritance
> with interfaces?
It's *not* strictly speaking a replacement. It's the splitting off of one
of the two areas of multiple inheritance (MI) functionality/use.
MI, as it's is in e.g., C++ and Eiffel, blends the notion of the
inheritance of the implementation with the inheritance of the API (or just
plain 'interface'). This intertwinedness causes a number of painful
problems. By splitting those two concepts apart we can gain a lot back in
terms of performance, understandability, precision of expression, etc.
Java only has single inheritance (SI) of implementation but supports
MI of interface (MII). This gives Java the ability to do the sorts of
things that people really, mostly want out of MI in e.g., C++.
As Terence has pointed out, modelling classes in C++ using the is-a
relationship that comes with C++ MI is just plain wrong. But in C++ you
have no other choice (well, delegation but that's just making the problem
into a manual issue).
A key thing to note though is that the Sather language has gone whole hog
and allows SI and MI but also has the capability of single/multiple
inheritance of just interfaces or just implementation. So you can mix and
match as you please. From discussion here and elsewhere with the Sather
folks (and especially Matt Kennel) I've grown to appreciate this clean
design of Sather.
> I haven't had enough OO experience to have run into the problems myself.
> But from what I've seen of Eiffel multiple inheritance is extensively
> used and to good effect.
MI in Eiffel is used for many things. One thing to note though is that
Eiffel MI is so much more tightly constrained due to the design of the rest
of the language that it's, IMHO, much better than C++ MI. Unfortunately,
you still haven't broken the bonds of the mis-use of the is-a relationship.
If I understand at least part of the long drawn out Co- vs Contra-variance
arguments in comp.object, this is one of the serious areas of complaint
because the is-a relationship is, in these languages, central to the issue
of the type system. [Catching up on that battle is left as an excersise for
the reader. :-]
> I imagine that the problem must be more than just possible name clashing
> as the Eiffel rename operator is a simple fix to this.
Yes, it's the inappropriate mixing of two very different things that can
cause problems. My (very humble) math background has taught me the virtues
of orthogonality.
> It seems to me that interfaces may be too restrictive. For a start it
> doesn't allow the following
>
> class A {
> int method1(); // abstract - no implimentation
> method2(); // abstract - no implimentation
> method3() { // full implimentation
> if (method1())
> method2();
> }
> }
>
> So you can't create methods that build on top of abstract methods.
>
> Or another example
>
> Class B {
> int method1(int a, float b, int c); // abstract
> int method1(int a, float b) {
> method1(a,b,0);
> }
> int method1(float b) {
> method1(0,b);
> }
> }
>
> which I'm not sure (I must confess) would work in Eiffel
Well, hmm... Yes, just having SI and MII in Java is more restrictive than
Sather and (I can believe that there are such possiblities in) Eiffel. But
those arguments are not *against* interfaces but rather arguments for
having MI of implementation too.
I really like the Sather language and it's handling of the whole
inheritance swamp is pleasingly rational. I do not, however, have any idea
whether or not it's worth the increased complexity of the language and/or
translators. Matt says it would be relatively easy to add (I'm
paraphrasing him so any errors are mine :-) but I don't have thought about
how it would effect other areas in the langauge (other than things like
'super'). Part of my intense fondness for Java is that it's simple. It's
not so pretentious as to be trying to be everything for everybody. At this
point, I would personally much prefer erring on the side of simplicity.
> Also Eiffel lets you defer deciding whether a feature with no arguments
> should be a method or an attribute.
[...]
> i.e we can define a precondition based on an abstract feature for another
> abstract feature. Whats more since haveFingers has no arguments it may
> be implimented as a method or as an attribute (i.e a state variable). (It
> could clearly be a state variable that is set by various methods or it
> could be a method that performs a count of other state variables.)
I agree, that's a nifty feature of Eiffel. You can do the same in Java by
just having all of your 'state' testing be from methods. You have just
made those testing methods part of that 'interface' and so there are
tradeoffs (though I thinks in this instance it's probably a wash).
> So regardless of whether it is a method or a state variable it is an
> assertion that is more than a check of "message arguments and their
> return values" and still says nothing about implimentation.
Okay, I'll buy that.
Hope this helps,
John
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
