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
signature.asc
Description: This is a digitally signed message part
