Martijn Dashorst wrote:
On Wed, May 21, 2008 at 2:19 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
Generics are hard, especially for library/framework designers: it's hard to
get them exactly right, especially with wildcards in complex cases. But just
because they are not currently exactly right yet in M1 seems no reason to
throw them all overboard again...

Not only for framework designers. *I* as a user of Wicket don't know
how to perform a setResponsePage() with the above code. This is not a
problem for framework designers. This is generics getting out of
control.

Well the fact that setResponsePage doesn't work with just a Page class seems to be an issue of the framework not the user (and yes it may be caused by an issue with generics, but in the end, the user of the framework should just be able to do: setResponsePage(MyPage.class) as they always did, and as is logical).

They make my code unreadable, hence unmaintainable. There is little
benefit of removing those 2 casts (where I never have had any
problems) compared to the UGLY stick that generified component smacks
on my code.

I agree that generics are overly verbose sometimes... but they give you back extra type safety. I guess whether you like this tradeoff or not is a personal choice (I like it, even though I would have preferred less verbose code and I hate erasure).

Generified component touches *ALL* code in Wicket, wether you care or
not. IModel<T> itself is rather contained.

Yes, but in my opinion rather useless as well. Plus you get heaps of @SuppressWarnings all over the place. Then just get rid of generics completely...

Regards,
Sebastiaan




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to