BIG +1 from me on this post! especially as everyone can set his compiler to ignore the generics when he dont want them while they save much time for devs that use them Regards _____
Von: Philip A. Chapman [mailto:[EMAIL PROTECTED] Gesendet: Montag, 19. März 2007 19:26 An: wicket-dev@incubator.apache.org Betreff: Re: generics in Wicket Guys, I've used generics with 2.0 at length, and absolutely love them. I am a huge fan of catching a problem early with compile-time errors rather than finding out later that I'm returning the wrong type from a model or that my Formatter is expecting a different type. Yes, for a while the angle brackets are ugly and annoying. Heck the first time I saw C style language, I thought that all the braces where ugly as sin. When I first began using annotations, I found it hard to read. Now? I've used all these things and have learned how to read them without having to stare at them a long time. Now I can move on to using them to make my code better. You do not *have* to use generics even with a generified framework. You will have to do a lot of casting and get a lot of compiler warnings, but it is not required. Nothing keeps you from defining a variable as a ListChoice rather than ListChoice<MyUserBean>. I, on the other hand use ListChoice<MyUserBean> extensively. To take that away would require that I touch a lot of code. For you, it requires that you ignore compiler warnings. All in all, I don't care much about the constructor change, but I consider generics to be a must-have. Anyway, that's my 2 cents. Your mileage may vary, of course. On Sun, 2007-03-18 at 22:22 -0700, Ryan Holmes wrote: Sure, but converters shouldn't necessarily be more tightly coupled to models either. Converters might use more fine grained types than a model, for instance (although I do see your point -- if objects are naturally tightly coupled there's no reason to pretend they're not). I guess I'm looking at this from a fundamentally different point of view: I've been getting by just fine with Wicket 1.2 (better than fine -- I freakin' love it) and haven't once been bothered by the lack of generics. I end up with maybe one or two casts in a page which just isn't a big deal. At the same time, generic components seem to add little and cost a lot in terms of productivity, readability and upgrade effort. So I totally agree that some things are nicer with generics. But that doesn't mean that generic components are the right design. I mean, are there demonstrable advantages to generic components that make Wicket a better framework and/or improve the API from a user's point of view? Or are generic components strictly a side-effect of generic models? -Ryan On Mar 18, 2007, at 6:35 PM, Igor Vaynberg wrote: > the thing is the model ties into a few places in the component > > for example IConverter Component.getConverter(). it would be nice > to say new > WebMarkupContainer<Person> { IConverter<Person> getConverter() {...}} > > things like that > > -igor > > > On 3/18/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> >> Hi Ryan, >> >> The problem is - I found out later - that we can't really generify >> models in a meaningful way without generifying components as well. At >> least, I haven't found a good way. >> >> Do you have concrete suggestions or a proposal of how we could >> implement generics in a meaningful but non-obstrusive way? >> >> Eelco >> >> >> On 3/18/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: >> > I think generic components are a mistake for several reasons. Not >> > only is the snippet below ugly and redundant, it doesn't even >> save a >> > cast if you're using a CompoundPropertyModel (which is the most >> > common case in my app). Well, I guess you save one cast, but that's >> > for the parent component's model, not for the form components >> > themselves. >> > >> > At least for FormComponents, it's relatively obvious that a >> > component's type == its model type. But what does it mean to >> specify >> > the type for a Panel, Link, WebMarkupContainer, etc. when you're >> not >> > even going to assign a model to the component (again, a fairly >> common >> > case)? I think classes that make sense as generics don't have this >> > problem -- they always hold, accept or return objects of their >> > specified type. >> > >> > A lot of this boils down to the fact that a component's type >> > parameter really has little to do with the component itself. >> It's for >> > the underlying model (including validation/conversion to the >> model's >> > object). Specifying the model's type in the component tightly >> couples >> > the two together, which clashes with Wicket's concept of models as >> > independent and dynamically resolvable objects (not to mention >> > clashing with MVC in general). >> > >> > So, I completely agree with everything you said below and just >> wanted >> > to throw out a "-1" for generic components hopefully before a final >> > decision is made. >> > >> > -Ryan >> > >> > >> > On Mar 6, 2007, at 9:57 PM, Eelco Hillenius wrote: >> > >> > > Hi, >> > > >> > > I think we went overboard applying generics in Wicket. >> > > >> > > Things like: >> > > TextField<Integer> integerTextField = new TextField<Integer> >> (this, >> > > "integerProperty", Integer.class); >> > > >> > > are just horrible imo. Sure, you can do: >> > > >> > > Integer i = integerTextField.getModelObject(); >> > > >> > > instead of: >> > > >> > > Integer i = (Integer)integerTextField.getModelObject(); >> > > >> > > but that's about the whole great benefit of generic components >> for the >> > > price of about twice the verbosity. >> > > >> > > Also, calling getModelObject is the kind of convenience method >> that >> > > grew upon us but that I personally never liked. It saves an >> ugly model >> > > check, fine, but in general I think users should try to >> directly work >> > > with models and their underlying objects instead. >> > > >> > > I can see the method come in handy in list views (on >> ListItem), though >> > > then again, you know the model object would never be null >> there so >> > > getModel().getObject() would work as well. >> > > >> > > Anyway, what I'd like us to consider is to de-generify >> components and >> > > only keep it for models. For certain components (like >> ListView) we/ >> > > users can decide to introduce it, but the general case would >> be to not >> > > to. >> > > >> > > Thoughts? Screams? >> > > >> > > Eelco >> > >> > >> -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
