[3750] in java-interest
Re: Fundamental flaw in Java library distribution scheme
daemon@ATHENA.MIT.EDU (David Strauss)
Sat Nov 25 15:47:08 1995
Date: Sat, 25 Nov 1995 13:38:00 -0500 (EST)
To: java-interest@java.sun.com
From: dstrauss@panix.com (David Strauss)
In article <199511250924.KAA20317@8670-news.bill.cdt.luth.se>,
perry@cdt.luth.se1 says...
>
>Excuse me for disturbing your discussion, but here goes...
>
>As in David's example, let's assume that we have a class C that
>extends Object, and a class L that uses class C. Let's further
>assume that class C does not define any equals() method, so a
>call in L to C.equals() will call the inherited equals(Object obj)
>from class Object.
>
>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.
>
>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!?
>
>--
>Per
>
>
>
>-
>This message was sent to the java-interest mailing list
>Info: send 'help' to java-interest-request@java.sun.com
No, it wouldn't be "strange" if the argument of the call were, in fact,
of type C, which is when it would occur. I think what's being argued
for is run time, rather than compile time, binding of overload
resolution. I don't find the idea strange. I'm not sure what the run-time
overhead issues might be, however.
--
------------------------------------------------
David Strauss
E-mail: dstrauss@.panix.com
dstrauss@lehman.com
-------------------------------------------------
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
