problem with method overloading
in [Java Programming]
|
From: Mike Schilling on 14 Jun 2010 22:28 "Lew" <lew(a)lewscanon.com> wrote in message news:39d4d747-e199-45cb-a22c-a23ddf6052b6(a)a29g2000vbl.googlegroups.com... > Lew wrote: >>> If 'equals(Object)' is not overridden, then it likely returns 'false' >>> even for an argument where 'equals(Foo)' would return 'true' if it were >>> invoked on the '(Foo)' cast of that instance. Programs usually invoke >>> 'equals(Object)', not 'equals(Foo)', so you get results you don't >>> expect. >> > > Simon Brooke <stillyet+n...(a)googlemail.com> wrote: >> OK, this is because selector-method resolution is done at compile time, >> not at run time as it would be in CLOS and in some other object oriented >> languages... yes? >> > > I don't know anything about CLOS. It's not relevant anyway, nor are > those other languages. In other words, "yes, Simon, you're correct".
From: Vikram on 14 Jun 2010 23:01 On Jun 15, 5:02 am, Joshua Cranmer <Pidgeo...(a)verizon.invalid> wrote: > On 06/14/2010 12:20 PM, Vikram wrote: > > > And we invoke the method as : test(null) : from another class, the > > method with the String parameter is executed. Any particular reason > > for this? > > JLS 3 15.12.2, your goto resource for pretty much any question about > why a method invocation is doing what it is doing. > > A brief overview of what happens in this particular case: > First, the compiler selects all the possible methods that the invocation > could match based on name and arity (in the absence of varargs, which is > a bit trickier) ( 15.12.1 and 15.12.2.1 goes into this in more detail > if you really want to know, but it's pretty intuitive). In your case, > this is both of the test methods. > > After that, the compiler looks at types to figure stuff out. If you > regress to pre-1.5 functionality, the subtyping is pretty simple. The > compiler is basically asking "how well do each of these methods match > what the user is trying?"; all expressions have types (the assignment of > types is fairly straightforward, see most of 15 if you really want to > know in full gory detail), so it's trying to match the types to the > types that the method supports--identifying matching methods by subtyping.. > > All types have supertypes: it is pretty much the same relation between > classes and superclasses, so all reference types are subtypes of Object. > The null type's supertypes are all reference types other than null. > > In your case, you have an expression whose type is the null type. Since > null is a subtype of String and Object, this phase of the search selects > both test methods. In the next phase, we need to choose between them. > The powers that be decided that the most intuitive thing to do is to > select the "most specific" method, where "most specific" has particular > meaning. In the absence of generics, if method A is more specific than > method B, than the arguments of A have declared types that are subtypes > of method B's arguments. Under this definition, test(String) is more > specific than test(Object), so it is the one chosen. > > Note that if you also had a test(Set) method, there would be no most > specific method, and the compiler would complain at you as a result. > -- > Beware of bugs in the above code; I have only proved it correct, not > tried it. -- Donald E. Knuth Thank you very much. Its quite clear now. Regards, Vikram
From: Lew on 14 Jun 2010 23:08 Lew writes: >> Use @Override here Arne Vajhøj wrote: > If a recent Java version. Five-and-a-half-plus years' recent since it was introduced in a Java version itself already officially obsolete. I felt it was pretty safe to mention on the "off" chance the poster had access to a version newer than eight years old and was not discussing ME edition. Whatever happened to the notion that "recent" in software meant somewhat less than four years old? How long will it take before JLS 3rd ed. and Java 5+ are no longer consider probationary? How is it that the vast and significant improvements of Java 5 and later over 1.4 and earlier, including the repair of the memory model for example, are not overwhelmingly compelling by now? Does Java 5 have to be twenty-one and allowed to buy booze before we recognize that it's an established product and not some Johnny-come-lately? Five years in software years is thirty-five in dog years, for Pete's sake! Regardless of the above rant, the OP being a new student of Java must surely be using at least Java 5, and therefore the advice was virtually certain to be relevant. And if he isn't, then he'd darn well better spend the zero dollars/euros/rupees and hurry up and buy Java 6 at no cost. (Java 6 isn't even recent any more, having been out for over four years.) "Recent", indeed. Pah! -- Lew
From: Alessio Stalla on 15 Jun 2010 03:28 On Jun 15, 12:37 am, markspace <nos...(a)nowhere.com> wrote: > Lew wrote: > > Simon Brooke <stillyet+n...(a)googlemail.com> wrote: > >> OK, this is because selector-method resolution is done at compile time, > >> not at run time as it would be in CLOS and in some other object oriented > >> languages... yes? > > > I don't know anything about CLOS. It's not relevant anyway, nor are > > those other languages. > > Basically, Simon is correct. Java and C++ implement single dispatch in > their method overloading resolution. Both languages have to implement > double dispatch manually, which is the reason for the Visitor pattern. > Lisp and a few other languages implement double dispatch (or > multi-dispatch) natively, although I believe there's a considerable > runtime cost overhead. Multiple dispatch in CLOS is done entirely at runtime. While reasonable implementations of CLOS use caching strategies to mitigate runtime costs, they can't match the efficiency of Java/C++ virtual method dispatch, which most of the time is just a pointer dereference + a function call (if the JIT doesn't inline the call; else it's even faster). In fact, even in heavily OO Lisp programs, "virtual methods" (using C++ terminology) are not used for everything like they are (almost) in Java: plain functions are used when runtime dispatch is not needed. So, imho, multiple dispatch is very powerful but only makes sense in languages which don't use OO for everything; else, its performance is probably too bad. Cheers, Alessio
From: Arne Vajhøj on 15 Jun 2010 21:51
On 14-06-2010 23:08, Lew wrote: > Lew writes: >>> Use @Override here > > Arne Vajhøj wrote: >> If a recent Java version. > > Five-and-a-half-plus years' recent since it was introduced in a Java > version itself already officially obsolete. I felt it was pretty safe to > mention on the "off" chance the poster had access to a version newer > than eight years old and was not discussing ME edition. > > Whatever happened to the notion that "recent" in software meant somewhat > less than four years old? How long will it take before JLS 3rd ed. and > Java 5+ are no longer consider probationary? How is it that the vast and > significant improvements of Java 5 and later over 1.4 and earlier, > including the repair of the memory model for example, are not > overwhelmingly compelling by now? Does Java 5 have to be twenty-one and > allowed to buy booze before we recognize that it's an established > product and not some Johnny-come-lately? Five years in software years is > thirty-five in dog years, for Pete's sake! > > Regardless of the above rant, the OP being a new student of Java must > surely be using at least Java 5, and therefore the advice was virtually > certain to be relevant. And if he isn't, then he'd darn well better > spend the zero dollars/euros/rupees and hurry up and buy Java 6 at no > cost. (Java 6 isn't even recent any more, having been out for over four > years.) > > "Recent", indeed. Pah! Recent has some relative associations. Recent ice age and recent political scandal have some different magnitudes. And you know as well as I do that Java has a huge backlog regarding upgrading software. But I completely agree that if starting with a blank sheet of paper, then version older than 1.6 should not even be considered. And I expect ME to die soon. Todays embedded devices can run SE. Arne |