[3752] in java-interest
Returned mail: Host unknown (Name server: bendenweyr.eng.sun.comt: host not found)
daemon@ATHENA.MIT.EDU (Mail Delivery Subsystem)
Sat Nov 25 15:48:56 1995
Date: Sat, 25 Nov 1995 13:58:53 -0500 (EST)
From: Mail Delivery Subsystem <MAILER-DAEMON@panix.com>
To: <java-interest@java.sun.com>
The original message was received at Sat, 25 Nov 1995 13:58:41 -0500 (EST)
from dstrauss.dialup.access.net [166.84.251.128]
----- The following addresses have delivery notifications -----
<flar@bendenweyr.Eng.Sun.COMt> (unrecoverable error)
----- Transcript of session follows -----
550 <flar@bendenweyr.Eng.Sun.COMt>... Host unknown (Name server: bendenweyr.eng.sun.comt: host not found)
----- Original message follows -----
Return-Path: java-interest@java.sun.com
Received: from dstrauss.panix.com (dstrauss.dialup.access.net [166.84.251.128]) by panix.com (8.7/8.7/PanixU1.3) with SMTP id NAA25530 for <flar@bendenweyr.Eng.Sun.COMt>; Sat, 25 Nov 1995 13:58:41 -0500 (EST)
Date: Sat, 25 Nov 1995 13:58:41 -0500 (EST)
From: java-interest@java.sun.com
Message-Id: <199511251858.NAA25530@panix.com>
To: flar@bendenweyr.Eng.Sun.COMt
Newsgroups: comp.lang.java
Subject: Re: Fundamental flaw in Java library distribution scheme
Distribution: world
Organization: Your Organization
X-Newsreader: WinVN 0.99.6
References: <9511251036.AA06745@8973-news.bendenweyr.Eng.Sun.COM>
MIME-Version: 1.0
Content-Type: Text/Plain; charset=ISO-8859-1
In article <9511251036.AA06745@8973-news.bendenweyr.Eng.Sun.COM>,
flar@bendenweyr.Eng.Sun.COMõ says...
>
>
>Hi Per (sorry to have gotten your name wrong the last time :-(),
>
>> > > 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.
>
>This is a key point to understand.
>
>If you provide a method with even the slightest change in any of the
>types of any of the arguments in a subclass as compared to an inherited
>method you have absolutely not overridden the method, you have instead
>overloaded it (as per the definition of these terms in Java). In the
>example in question:
>
> class Object {
> public void equals(Object obj);
> }
> class C /* implicitly extends Object */ {
> public void equals(C obj);
> }
>
>The C.equals method does not override the Object.equals method. It
>overloads the method and it is essentially a distinguishable, or new,
>method that must be specifically chosen at compile time. If the
>argument had been declared as type Object, then it would override the
>first method and would automatically be chosen whenever the original
>equals(Object) method was invoked on an object of type C.
>
>So, when you say '"old" method, but with new contents' above you are
>defining something that is overloading and not overriding. It is a new
>method (in the sense that overloading methods creates new methods that
>happen to share a common name), and it is not "just an overridden one"
>(which in Java would require it to have the *exact* same signature).
>
> ...jim
>-
>This message was sent to the java-interest mailing list
>Info: send 'help' to java-interest-request@java.sun.com
You are just saying again that overload resolution is done at
compile time. I think everybody knows that. David is arguing
that it should be done at run time. What needs to be debated
here is whether or not this is a sound idea, and what the
overhead would be. The argument
that it would be more consistent with Java's stated goal
of being able to do transparant library distribution seems
well taken.
--
------------------------------------------------
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
