[3748] in java-interest
Re: Fundamental flaw in Java library distribution scheme
daemon@ATHENA.MIT.EDU (Per Danvind)
Sat Nov 25 06:41:21 1995
To: flar@bendenweyr.Eng.Sun.COM (Jim Graham)
Cc: java-interest@java.Eng.Sun.COM
In-Reply-To: Your message of "Sat, 25 Nov 1995 01:40:54 PST."
<9511250940.AA06664@bendenweyr.Eng.Sun.COM>
Date: Sat, 25 Nov 1995 11:18:16 +0100
From: Per Danvind <perry@cdt.luth.se>
> =
> Hi Perry,
> =
> > David points out that if you change class C to include an
> > equals(C obj) method, but only recompile the C class, L will
> > still call the inherited equals(Object obj) from Object even if
> > the argument is a C object. That is until class L is recompiled
> > as well.
> =
> Class L might call the C.equals(C obj) method, or it might call
> the Object.equals(Object obj) method. It depends on how the
> arguments are cast in the specific call. In particular, if you
> call:
> =
> public void foo(C target, C obj, Object obj2) {
> target.equals((Object) obj); // Case 1
> target.equals(obj2); // Case 2
> }
This is well known, and can often be of use.
In my example though, the new method equals(C obj) is not known to
L since only C was recompiled, not L. =
> Then the Object.equals(Object obj) method will be called in both cases,=
> bypassing the C.equals(C obj) even if both obj arguments happen to be
> of class C, because in the first case this method explicitly used
> casting to choose the method it wanted, and in the second case the
> compile time type of obj2 can only proven to be as specific as
> "Object".
> =
> This is how you can affect the compile time choice for which overloaded=
> operator will be used, by controlling the visible types of the
> arguments in the line containing the method call. On the other hand,
> without the cast, then yes, when class L is recompiled it will switch
> from using Object.equals() to C.equals() for the first case since that
> new method will be determined to be more specific.
> =
> > This is not wrong. Class L can't know that there now is a new
> > method in class C. Think about it. If you add a method to a class
> > C, wouldn't it be strange if classes using that class, suddenly
> > started calling this new method, without even being recompiled!?
> =
> The beauty of Java is that if you override a method, which involves
> using the same arguments as the inherited method exactly, then the
> new method *will* get called automatically at runtime *without*
> recompilation!
But it isn't really a new method, just an overridden one, i.e. the
"old" method but with new contents. I think you said this yourself,
that if a method is overloaded you get a completely new method, but
if a method is overridden, it just gets new contents.
> But, in order to get the benefit of this dynamic dispatch of the
> overriden method, you must use exactly the same argument types
> and return type in the method as the inherited method. That is
> the distinction that seems to be misunderstood in this discussion.
> =
> ...jim
--
Per
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
