no worries, i wasnt holding my breath. its just that when i make sweeping statements i tend to have something to back them up that other people can see...
-igor On Tue, Jun 3, 2008 at 8:19 PM, Brill Pappin <[EMAIL PROTECTED]> wrote: > > You will wait a long time for an example generated from "the API would be > different" in such and such a case, based on an opinion. > > If your really all that interested you could start from scratch using > generics and see what came out. > Let me know if you do, because I'd be interested to see if my opinion held > any merit. > > However, if your interested in why I said that in the first place, then I > can explain that. > > I don't know if you have every done true TDD (most people can't or think > they can), but it actually changes your code and the way you write it. > Starting with 2 users of your code makes a significant impact on what it > looks like in the end. > I applied the same thoughts to using generics from the start, and realized > the API would likely be a bit different. Exactly how much, I wouldn't > presume to guess. > > - Brill Pappin > > -----Original Message----- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 11:03 PM > To: users@wicket.apache.org > Subject: Re: users, please give us your opinion: what is your take on > generics with Wicket > > 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] > > > --------------------------------------------------------------------- > 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]
