[3756] in java-interest
Re: Fundamental flaw in Java library distribution scheme
daemon@ATHENA.MIT.EDU (Pat Niemeyer)
Sat Nov 25 18:28:37 1995
Date: Sat, 25 Nov 1995 16:01:11 -0600 (CST)
From: Pat Niemeyer <pat@icon-stl.net>
To: Jim Graham <flar@bendenweyr.Eng.Sun.COM>
Cc: perry@cdt.luth.se, java-interest@java.Eng.Sun.COM
In-Reply-To: <9511251036.AA06745@bendenweyr.Eng.Sun.COM>
On Sat, 25 Nov 1995, Jim Graham wrote:
> 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.
Ah, that statement cleared up some things that I hadn't thought through
properly before:
So, over-ridden methods are found dynamically at run-time, but over-loaded
methods have to be known to the calling class at compile time to be found.
Presumeably this is because the method signature is stored in the calling
class and the run-time tries to hunt for a match in the target class. (?)
I guess the latter type - doing runtime sub-type matching would be
really expensive...
Pat
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
