The reflection API does have methods for enquiring about generic type
information. So although the actual generated code has no types (as
Andrew shows), I think the information that the compiler uses to do type
checking is encoded in the class file somehow.
I would think that this means that there *is* some way to get the
type-safety back using a reflection-based layer.
Regards,
Simon
Pesia wrote:
Thanks!
Ofcourse you're right!
I was confused (because I used to templates in C++ - where compiler
generates different type for each generic object instead of "cheating" like
here).
(a link for those who are interested in more details:
http://www.mindview.net/WebLog/log-0050
http://www.mindview.net/WebLog/log-0050 )
Unfortunately that means to me that I have to abandon my very elegant
solution to handle different types binding.
I have no clue how to do it in different way (Probably I will be forced to
create my custom class manually
for every possible type of value plus converters for all those types?).
I would like to have automatic conversion of values to proper types (because
I know concrete types only at runtime). For example I have table row of data
with columns
[Integer, String, Date, Integer]
(those types are known only at runtime) and I would like to bind this row to
appropriate form fields (form would be also generated in dynamic way basing
on row contents).
Or maybe there is a way to simulate C++ template behavior using reflections
for example? Has anybody tried similar approach?
Best Regards
Maciej Pestka
Andrew Robinson-5 wrote:
Yes your code:
class ValueWrapper<T>{
private T value;
public void setValue(T value){
this.value = value;
}
public T getValue() {
return this.value;
}
}
Actually looks like this to the JRE (I'm pretty sure):
class ValueWrapper{
private Object value;
public void setValue(Object value){
this.value = value;
}
public Object getValue() {
return this.value;
}
}
Only the compiler knows what type of object your code wants.