 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2006polymorphic voodoo?
Ok, here is what I am trying to decipher. I have the following code private void someMethod() { ArrayList list1 = null; LinkedList list2 = null; cleverFunction(list1,list2); } private void cleverFunction(List first, List second) { System.out.println("Static type for first is " + .....); System.out.println("Static type for second is " + .....); } Ok, so, given a polymorphic call like this, is it possible, through whatever witchcraft necessary, to determine what the static types of the type polymorphic parameters are? Maybe some sort of interrogation of the stack? Maybe some sorta reflection? Ideas? christian http://christian.bongiorno.org/resume.PDF > Ok, here is what I am trying to decipher. I have the following code > [quoted text clipped - 14 lines] > whatever witchcraft necessary, to determine what the static types of > the type polymorphic parameters are? You always know the static types of variables. In this case, the static type of both 'first' and 'second' is java.util.List. Did you want to know the static types of the actual parameters in the calling stack frame? In that case, things get harder. You'd need to have access to either debugging information or the source code for the calling function, since the information you're looking for is partially lost during the translation to bytecode. Let me make the obligatory statement that if you care, your design has probably gone horribly wrong.  SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation > Did you want to know the static types of the actual parameters in the > calling stack frame? In that case, things get harder. Err, first.getClass()? second.getClass()? EJP schrieb: >> Did you want to know the static types of the actual parameters in the >> calling stack frame? In that case, things get harder. > > Err, first.getClass()? second.getClass()? Err, NullPointerException? ;) Bye Michael > > Did you want to know the static types of the actual parameters in the > > calling stack frame? In that case, things get harder. > > Err, first.getClass()? second.getClass()? You're confusing type with class. As Michael pointed out, the values of these variables in the example are null, so they don't point to any objects and it won't work to ask for the object's class. Even if they weren't null, though, getClass() would be the wrong answer. That would tell you the class of the object, and not the type of the variable that points to it. As I said earlier, the types of the formal parameters are both java.util.List. Any other answer is wrong. The types of the actual parameters in the example given here are java.util.ArrayList and java.util.LinkedList. This would remain true even if the object pointed to were of class javax.management.AttributeList (a class that extends ArrayList). That still wouldn't change the type of the variable. It's worth mentioning that if one wants to know static types of the actual parameters out of a small set of options, then method overloading can do it. Since static types are, by definition, known at compile- time, this should be sufficient... but only if there's only a small set of options; otherwise, it becomes impractical or impossible. SignatureChris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation It's mostly academic. I have even thought about going so far as to load the actual class bytes and interrogate them. Later posts have suggested what I think is most likely: A Debugger. I am off the project now where I might have used something like this, but still think about what I might have done. > Let me make the obligatory statement that if you care, your design has > probably gone horribly wrong. > > -- > Chris Smith - Lead Software Developer / Technical Trainer > MindIQ Corporation >System.out.println("Static type for first is " + .....); >System.out.println("Static type for second is " + .....); >[...] is it possible [...] to determine [...] the static types >of the [...] [arguments]? Not really, but here is an approximation that might work sometimes: public class Main { static void printStaticTypesOfExpressions ( final java.util.ArrayList first, final java.util.ArrayList second ) { System.out.println( "java.util.ArrayList" ); System.out.println( "java.util.ArrayList" ); } static void printStaticTypesOfExpressions ( final java.util.LinkedList first, final java.util.ArrayList second ) { System.out.println( "java.util.LinkedList" ); System.out.println( "java.util.ArrayList" ); } static void printStaticTypesOfExpressions ( final java.util.ArrayList first, final java.util.LinkedList second ) { System.out.println( "java.util.ArrayList" ); System.out.println( "java.util.LinkedList" ); } static void printStaticTypesOfExpressions ( final java.util.LinkedList first, final java.util.LinkedList second ) { System.out.println( "java.util.LinkedList" ); System.out.println( "java.util.LinkedList" ); } public static void main( final java.lang.String[] args ) { final java.util.ArrayList list1 = null; final java.util.LinkedList list2 = null; printStaticTypesOfExpressions( list1, list2 ); }} java.util.ArrayList java.util.LinkedList > >System.out.println("Static type for first is " + .....); > >System.out.println("Static type for second is " + .....); [quoted text clipped - 37 lines] > java.util.ArrayList > java.util.LinkedList Issue being, the method called from main is determined at compile time as revealed by javap: public static void main(java.lang.String[]); Code: 0: aconst_null 1: astore_1 2: aconst_null 3: astore_2 4: aload_1 5: aload_2 6: invokestatic #42; //Method printStaticTypesOfExpressions:(Ljava/util/ArrayList;Ljava/util/LinkedList;)V 9: return >> >System.out.println("Static type for first is " + .....); >> >System.out.println("Static type for second is " + .....); >> >[...] is it possible [...] to determine [...] the static types >> >of the [...] [arguments]? [code snipped] > Issue being, the method called from main is determined at compile time Which is fine, because the static types are also known at compile time. - Oliver > >> >System.out.println("Static type for first is " + .....); > >> >System.out.println("Static type for second is " + .....); [quoted text clipped - 8 lines] > > - Oliver True but, I've (unfortuneately) seen more than a few cases where someone thinks it will happen at runtime Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.