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: [email protected] 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: [email protected] > 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]
