+1 This seems to be the best option so far. It's confusing to see a bunch of subclasses whose only purpose is to avoid generic type definitions. A separate dependency makes sense. If anyone is that concerned with having to define void generic types they can add the dependency.
-----Original Message----- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Saturday, May 24, 2008 10:51 AM To: users@wicket.apache.org Subject: Re: (Class<? extends Page<?>>) casting troubles thats funny, my primary usecase is to use link WITH a model. so why dont we keep Link generified and have a subclass VoidLink. i am also not a big fan of using class hierarchy essentially as a typedef, seems like a nasty hack to me (which i am willing to live with). perhaps we can have wicket-void module that can contain all these Void subclasses. -igor On Sat, May 24, 2008 at 2:24 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > +1 > > On Sat, May 24, 2008 at 8:09 AM, Daniel Walmsley <[EMAIL PROTECTED]> wrote: >> >> Just to quickly weigh in on the verbosity argument: >> As someone who has coded Java (and Perl, C++, etc) in every >> environment from individual projects to multinational finance >> systems, I will say that verbosity of code runs a far, far, distant third (or twentieth) to: >> 1. Readability/Understandability, and 2. Maintainability By >> illustrating succinctly what type of model (if any) a component will >> contain, generics in Wicket neatly accomplish point 1. >> By allowing your IDE to tell you when you're setting the wrong type >> of model object in a component it neatly accomplishes point 2. >> You write your code once. You maintain it thousands of times. The >> trade-off to me is perfectly clear, and this will be vindicated when >> Wicket-based enterprise projects start conspicuously succeeding where >> others have failed. >> Also, don't mistake "verbosity" for "DRY-ness". COBOL was verbose >> because it forced you to repeat yourself over and over. Java supports >> very elegant reuse, so each piece of functionality is written just >> once. Thanks to Annotations we've cut down (significantly) on >> boilerplate, and the whole appeal of Wicket is its ability to enable >> reuse at the web tier. Between generics, annotations and component >> reuse, this makes Wicket a very DRY-friendly framework, and has >> vastly reduced the amount of code I've had to cut for my clients. >> I've used every framework under the sun (no pun intended) and Wicket >> rules over them all. >> Cheers, >> Dan >> On 22/05/2008, at 07:20AM, Jonathan Locke wrote: >> >> I'm jumping into this conversation very late and I simply can't catch >> up on this entire thread, but isn't it possible to have a non-generic >> build of the generic framework for people that don't want to use >> generics? >> >> Skimming this discussion, in general, I tend to agree with Eelco. A >> good general approach would be to fully generify the framework and >> then vote to back out the things which are really not helpful (for >> example, although page is technically a component, pages often have >> no models, so it might be a good thing to a un-generify). Once we >> have found a practical/optimal level of generification should we vote >> on it. Let's not throw the baby out with the bathwater. >> >> Also, for myself, I disagree that type safety is not a primary goal >> of generics. Even if the API were completely clear already, I'd still >> prefer more type safety. >> >> >> Martijn Dashorst wrote: >> >> On Wed, May 21, 2008 at 5:05 PM, Johan Compagner >> <[EMAIL PROTECTED]> >> >> wrote: >> >> Generics is type safety >> >> I didn't say generics isn't type safety. But APPLYING generics for >> the >> >> Wicket framework API *ISN'T* its primary goal. API clarity *IS*. Less >> >> questions on the mailing list regarding DDC, ListView, etc. is the >> >> main goal for applying generics in Wicket. >> >> I am against this abuse big time -1000 from me >> >> I'm -1000000000000000^1000000000000 for abusing my eyes and brain in >> >> the way it currently is implemented in Wicket. It is completely and >> >> utterly unusable for beginners. There is no way this is going to make >> >> the number of questions on the mailinglist less (other than by >> scaring >> >> away anyone that wants to actually use the framework) >> >> Martijn >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> -- >> View this message in context: >> http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting >> -troubles-tp17355847p17375350.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> Daniel Walmsley >> Director, Firesyde >> e: [EMAIL PROTECTED] >> m: +61404864141 >> > > --------------------------------------------------------------------- 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]
