[
https://issues.apache.org/jira/browse/WICKET-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075614#comment-14075614
]
Sven Meier commented on WICKET-5350:
------------------------------------
Hi Eric, many thanks for chiming in.
IMHO the Model#of...() signatures are the central cause for much of the current
wildcard inconveniences. I don't think we can do much about it in Wicket 7
though :(.
I'd be interested in any examples that is not handled by my proposed changes.
> wildcards elsewhere in Wicket ... whether I can exorcise them too
I've spent a few days looking through many parts of Wicket code, to make sure
we don't lose any flexibility in the usage of components. Some signatures look
daunting, but they don't come into your way if you don't care.
>Is there any interest in that?
Sure, the more people are involved, the higher the chance that we get it right
this time.
> Enhancement for AbstractChoice and WildcardListModel API
> --------------------------------------------------------
>
> Key: WICKET-5350
> URL: https://issues.apache.org/jira/browse/WICKET-5350
> Project: Wicket
> Issue Type: Improvement
> Affects Versions: 6.10.0, 7.0.0-M1
> Reporter: Betlista
> Assignee: Sven Meier
> Priority: Minor
> Labels: generics
>
> According to Efective Java book
> (http://devender.files.wordpress.com/2008/05/effectivejava.pdf), item 28:
> "No wildcard type for return value"
> Especially "User should not have to think about wildcards to use your API".
> so
> public List<? extends E> getChoices()
> should be changed to
> public List<E> getChoices()
> and for WildcardListModel
> protected List<? extends T> createSerializableVersionOf(List<? extends T>
> object)
> should be changed to
> protected List<T> createSerializableVersionOf(List<? extends T> object)
> Probably there is a lot of such things in framework.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
