Opinion, not statement :) But i get where your coming from. - Brill
On Tue, Jun 3, 2008 at 11:29 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
