this only works for subclasses. and if you do class myclass<a,b> extends otherclass<b> you have to map the entire class hierarchy to figure out how [0] maps to your expected type. in the example above you actually want [1].
-igor On Fri, Oct 31, 2008 at 7:23 AM, Bernard Niset <[EMAIL PROTECTED]> wrote: > Hi Martin, > There *is* a way to evaluate the type parameter at runtime. Something like > the following will give you the first type used: > > (Class<T>) ((ParameterizedType) getClass() > .getGenericSuperclass()).getActualTypeArguments()[0] > > Regards, > Bernard. > > Martin Voigt a écrit : >> >> if we could get something like >> >> <T default Void> >> >> from sun, all my generics problems would go away. >> >> no code clutter anymore just because you "generify" classes that >> should be. and type safety would still be ensured at runtime. if the >> vm would give me a way to evaluate the type parameter at runtime, i'd >> be more than happy, but that will stay a dream for a long time ;) >> >> Regards, >> Martin >> >> 2008/10/30 Ricky <[EMAIL PROTECTED]>: >> >>> >>> I don't know if i should speak up amongst elite group of people >>> discussing, >>> but hey i'll try ... :) >>> >>> From what i understand most people have issues with readability of >>> generics; >>> but as i have indicated time and again as java improves and generic types >>> become reified; and java becomes inferred static typed; generic notation >>> will be less DRY violating and more clear. >>> >>> But its the conceptual approach that i am not sure I am following (which >>> is >>> why said may be I shouldn't be posting this :)). A component has to have >>> an >>> associated model type with it. Generifying models is mandatory... but >>> from >>> what i see; not generifying components would be a big mistake. >>> >>> I cannot see any model less component. A component interacts with >>> underlying >>> application data using model wrapper ... that was the beauty of wicket >>> that >>> i had come to love the most and if now we are saying that it is valid in >>> some cases and in some it isn't is contradictory. If anything; for >>> consistency sake we should go with component level generification. But i >>> guess i am in the minority in that issue. >>> >>> Generics is something that java developers have to get used to and it >>> takes >>> some time ... but just because it takes some time; we should choose a >>> middle >>> ground solution isn't exactly right; may be more practical (oh well ;) ). >>> >>> On Thu, Oct 30, 2008 at 2:34 PM, Johan Compagner >>> <[EMAIL PROTECTED]>wrote: >>> >>> >>>> >>>> i agree and we only need 2 things to be fixed improved by sun and then >>>> all >>>> the current problems are completely gone.... >>>> But i guess we never get them >>>> Because they find JavaFX way more importand.. I am glad the focused on >>>> that >>>> because it gave us Java6U10 but that whole JavaFX i dont have much hope >>>> for >>>> that. >>>> >>>> johan >>>> >>>> >>>> On Thu, Oct 30, 2008 at 6:25 PM, Edward <[EMAIL PROTECTED]> >>>> wrote: >>>> >>>> >>>>> >>>>> Well I'll speak up and say I don't like generics in Wicket. I like >>>>> them >>>>> in other places... just not here. It is a lot of extra ugly code just >>>>> to fix the rare occurrence that I have to cast the model object. >>>>> >>>>> Not to mention in my opinion it breaks the data abstraction the model >>>>> provides. Might as well get rid of the model all together. >>>>> >>>>> When I first started using Wicket I admit I was shocked there were no >>>>> generics and I was accessing the model object all the time and casting. >>>>> As I got better at using Wicket though I found better ways of doing >>>>> things and I believe I haven't done a cast even once in the past 6 >>>>> months - and I have developed some fairly complicated apps in that >>>>> time. >>>>> >>>>> I think 1.3 is designed very well and I like it a lot. >>>>> >>>>> Edward >>>>> >>>>> >>>>> >>>>> Jan Kriesten wrote: >>>>> >>>>> >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> you are against generics completely. but they are going to happen. >>>>>> the >>>>>> >>>>>>> >>>>>>> way they are now is not perfect, in 1.5 we will try to move them to a >>>>>>> better place, but like it or not they are here to stay. >>>>>>> >>>>>>> >>>>>> >>>>>> huh - hell, no, I'm not against generics at all. Where do you get that >>>>>> from? I'm >>>>>> against generics on Components which are not FormComponents (or >>>>>> ListViews)! >>>>>> >>>>>> I'm using Wicket together with Scala and other than with Java, I can't >>>>>> just drop >>>>>> the generics attributes (and live with the warnings). And the <Void> >>>>>> is >>>>>> really a >>>>>> hell of a generic... >>>>>> >>>>>> Generics on Models are what is needed and if your vision to decouple >>>>>> models from >>>>>> the component and use introspection/reflection to support them comes >>>>>> >>>> >>>> true >>>> >>>>>> >>>>>> I'd be >>>>>> quite happy (and could use Scala's mixin-feature to have my model >>>>>> functionality >>>>>> on the components). >>>>>> >>>>>> Best regards, --- Jan. >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>> >>> -- >>> >>> Regards >>> Vyas, Anirudh >>> || ॐ || >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
