sorry, still waiting for an example here... -igor
On Tue, Jun 3, 2008 at 7:53 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: > Actually, i did not say "... say that wicket api needs a radical refactoring > in order to support generics" what I actually said was "I think that if > Wicket had been written with generics from the beginning, the API would be > different". > > No "radical refactoring required" was mentioned :) > > Big difference... It would be WAY too much work to rewrite it now, and I > think your right that it can be implemented fairly well without too much > impact on the users. > > - Brill Pappin > > -----Original Message----- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 12:21 AM > To: users@wicket.apache.org > Subject: Re: users, please give us your opinion: what is your take on > generics with Wicket > > you made a radical statement, just wandering if there is anything concrete > you can back it up with. in my head the generics have very little effect on > the actual api design so i am wandering what prompted you to say that wicket > api needs a radical refactoring in order to support generics - which > essentially are little more then metadata. > > -igor > > On Mon, Jun 2, 2008 at 8:50 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: >> So am I :) >> >> I think that just like TDD generates a whole new structure to your >> code (IMO a better one) that implementing generics at the start would >> have produced something a bit different. >> >> - Brill Pappin >> >> -----Original Message----- >> From: Igor Vaynberg [mailto:[EMAIL PROTECTED] >> Sent: Monday, June 02, 2008 11:42 PM >> To: users@wicket.apache.org >> Subject: Re: users, please give us your opinion: what is your take on >> generics with Wicket >> >> im really curious to hear what these changes would be... >> >> -igor >> >> On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: >>> >>> I think... >>> >>> We should be able to use the untyped variants, but the explanations >>> for why that won't work directly was valid. >>> >>> So on to you're A/B question. I don't think it matters much... The >>> people doing things "inline" are going to use that method anyway and >>> generics won't hurt them, but the usefulness to people who write more >>> extensive application is likely more important (if its that simple it >>> doesn't matter much, if its complicated then it is and can be used). >>> >>> >>> Allow me to digress. >>> I think that if Wicket had been written with generics from the >>> beginning, the API would be different... And that is the root of the >> problem. >>> I think that maybe a concerted refactoring effort *must* allow the >>> API to change (call it wicket 2.0 for all of us old struts users) in >>> order for things to work out properly. >>> I don't actually think that heavy a refactoring would be such a bad >>> thing. I love what Wicket has done, but I think it could be less >>> "black-boxy" as well. >>> >>> - Brill >>> >>> -----Original Message----- >>> From: Stefan Lindner [mailto:[EMAIL PROTECTED] >>> Sent: Monday, June 02, 2008 12:13 PM >>> To: users@wicket.apache.org >>> Subject: AW: users, please give us your opinion: what is your take on >>> generics with Wicket >>> >>> Brill Pappin wrote >>>>I don't know, I think the discussion is going *toward* generics. >>>>Frankly I can't even see why its an issue at all, the language has >>> evolved and uses them... Why would Wicket not also use them its >>> inline with >>>>the current state of the language? >>>> >>>>There is no reason that people who can't get their heads around >>> Generics can't use the older releases that don't include it, but IMO >>> any java >developer who doesn't get generics yet better make some >>> time to learn, because like it or not, they *will* be dealing with them. >>> >>> I agree totally with you. My expericence with Generics over the last >>> two years was that any project that was adopted to generics had much >>> less errors afterwards. >>> >>> But the main problem in this discussion seems to be that there are >>> two very different sorts of Web Applications that are developed with >>> wicket and both may have predecessors that are non generic. >>> >>> Type A: A Web applicatons that make heavy use of Models, like classic >>> desktop allications that are ported to the web. I think the >>> programmers of such applications like Generics becaus they help them >>> to avoid erros and the current wicket generic implementation leads to >>> a strong typed application that needs a good object model (and a good >> database design). >>> If you port an exisitng wicket application with no generic to wicket >>> 1.4 you might discover some unclear object model problems in your >>> exisitng code. And it's always easier to point to wicket's generics >>> than to blame your own code >>> :-) >>> >>> Type B: A Web Application with more static content, only some date >>> (like user logins, user profile data). In this case it's clear that >>> some people say "why should I always tyle 'Link<Void>', none of my >>> links has a Model, just about 10% of my Components have a Model". But >>> why dont't they write their own wrapper e.g. MyVoidLink extends >>> Link<Void>? I remember a dicsusson about such Components some weeks ago. >>> >>> >>> What do you think about it? Would it help users of Type B to have >>> VoidComponents? >>> >>> Stefan >>> >>> --------------------------------------------------------------------- >>> 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] >>> >>> >> >> --------------------------------------------------------------------- >> 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] >> >> > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
