[3751] in java-interest
Re: Fundamental flaw in Java library distribution scheme
daemon@ATHENA.MIT.EDU (David Strauss)
Sat Nov 25 15:47:17 1995
Date: Sat, 25 Nov 1995 14:08:58 -0500 (EST)
To: java-interest@java.sun.com
From: dstrauss@panix.com (David Strauss)
In article <497p1o$jg3@news1.panix.com>, java-interest@java.sun.com says.=
..
>
>In article <9511251036.AA06745@8973-news.bendenweyr.Eng.Sun.COM>,=20
>flar@bendenweyr.Eng.Sun.COM=F5 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!?
>>> >=20
>>> > 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!
>>>=20
>>> 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. =20
>
>--=20
>------------------------------------------------
>David Strauss
>E-mail: dstrauss@.panix.com=20
> dstrauss@lehman.com=20
>-------------------------------------------------
>
--=20
------------------------------------------------
David Strauss
E-mail: dstrauss@.panix.com=20
dstrauss@lehman.com=20
-------------------------------------------------
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
