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 > || ॐ || >
