 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2007Annotations and generic programming
Now, one of the big criticisms of type-erasure generic programming is that - well, it's type erasure generic programming: suppose you have public static <T> List<T> doStuff(){ ... } Within the body of doStuff(), T.class is an error, and the only way to get what T stands for is to use that big backhoe that's reflection and somehow get a Class<T> object - which you would do by passing in a Class<T>, resulting in... public static <T> List<T> doStuff(Class<T> tClass) { ... } Now IMO T.class should really return a Class<T>, just like Integer.class gives you Class<Integer>, but I guess that other peoples opinions differed (I am not sure about the argument against it, so please explain to me what it is). Why do I mention this? It seems like annotations and annotation processing might be a means to an address this. (If I am wrong about annotations or annotation processing, please correct me). It seems like there should be an annotation processor that would take code of the former form and convert it to code of the latter form (the needed Class arguments would be the first arguments passed in). Am I ill-informed on this, and if not, is there such an annotation processor? > Now IMO T.class should really return a Class<T>, just like > Integer.class gives you Class<Integer>, but I guess that other peoples > opinions differed (I am not sure about the argument against it, so > please explain to me what it is). Existing code would not work if it made use of classes that had been generified. There could have been some system where T.class may or may not give you the Class, but that would make Java an even bigger language. > Why do I mention this? It seems like annotations and annotation > processing might be a means to an address this. (If I am wrong about > annotations or annotation processing, please correct me). It seems > like there should be an annotation processor that would take code of > the former form and convert it to code of the latter form (the needed > Class arguments would be the first arguments passed in). No. No part of the code you quoted actually specifies the class of T. There is no way an annotation processor could get that information. Tom Hawtin > Now, one of the big criticisms of type-erasure generic programming is > that - well, it's type erasure generic programming: suppose you have [quoted text clipped - 13 lines] > > } Its not hard to do this anyway. List<Foo> foos = doStuff(Foo.class); If you wanted to take T.class, thats as much reflection as Foo.class, although it does put it in the client code. > Now IMO T.class should really return a Class<T>, just like > Integer.class gives you Class<Integer>, but I guess that other peoples > opinions differed (I am not sure about the argument against it, so > please explain to me what it is). The argument is that T is not a real type, but a type holder. Integer.class is a static constant, T.class could not be a constant, since T could represent Integer or FooBob. > Why do I mention this? It seems like annotations and annotation > processing might be a means to an address this. (If I am wrong about > annotations or annotation processing, please correct me). It seems > like there should be an annotation processor that would take code of > the former form and convert it to code of the latter form (the needed > Class arguments would be the first arguments passed in). Annotation processors take "@Annotation" annotations, and process them. There is no @Annotation in your code anywhere... Again, the type of T us up to the caller of doStuff, so you would have to know all of the callers before hand. This is not a possible task, as the calling code could be written and compiled after the fact. > Am I ill-informed on this, and if not, is there such an annotation > processor? There are annotation processors, and also reflection based frameworks which use annotations. They however are no use to your problem. It is considered appropriate to pass Class<T> type into methods as a type token. It even gives you the ability to call type.cast() if you need to. > Annotation processors take "@Annotation" annotations, and process > them. There is no @Annotation in your code anywhere... That's not necessary. Annotation processors can run on unannotated code, deriving information through conventions and defaults. Tom Hawtin > > Annotation processors take "@Annotation" annotations, and process > > them. There is no @Annotation in your code anywhere... [quoted text clipped - 3 lines] > > Tom Hawtin True, but its still no solution to the OPs problem. > Within the body of doStuff(), T.class is an error, and the only way to > get what T stands for is to use that big backhoe that's reflection and > somehow get a Class<T> object - which you would do by passing in a > Class<T>, resulting in... What about T.getClass()? > > Within the body of doStuff(), T.class is an error, and the only way to > > get what T stands for is to use that big backhoe that's reflection and > > somehow get a Class<T> object - which you would do by passing in a > > Class<T>, resulting in... > > What about T.getClass()? T is a type variable. getClass() works in instances. If I passed in an instance of T in my code, then we wouldn't need to pass in the Class<T>. However, that's a big if... > > > Within the body of doStuff(), T.class is an error, and the only way to > > > get what T stands for is to use that big backhoe that's reflection and [quoted text clipped - 6 lines] > an instance of T in my code, then we wouldn't need to pass in the > Class<T>. However, that's a big if... How would T.class be any less reflective than tObject.getClass()? What are you hoping to accomplish? 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
|
©2009 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.