Hi Sven,
It's easy to change the testcase to:
class NumberListView<N extends Number> extends ListView<N>
and
new NumberListView<Integer>("integers", integers)
I think the constructor in Wicket 6 is wrong. It should be IModel<? extends
List<T>> model: we don't care what type the list is, but we do care about the
type of the contents of the list. ListView exposes a read-write view on the
contents of the list, via ListView.getModelObject(), but also
ListItem.setModelObject. IMHO it should either be read-only with ? extends T
or read-write with T, but mixed. The first is a major API break, the second is
not, so I prefer the second.
Best regards,
Emond
On Monday 22 June 2015 14:22:25 Sven Meier wrote:
> Hi Martijn,
>
> the ListView constructor is now as it has been in Wicket 6:
>
> public ListView(final String id, final IModel<? extends List<?
> extends T>> model)
>
> ListViewTest#generics() shows a valid use case, that is not possible
> otherwise.
>
> Regards
> Sven
>
> On 22.06.2015 13:42, Martijn Dashorst wrote:
> > I'm not sure I'm fan of this change. Using these wildcards breaks all
> > kinds of code. What is the benefit?
> >
> > The way it is implemented currently is also inconsistent: ListItem is
> > typed as ListItem<T> but it should be ListItem<? extends T>. This
> > gist: https://gist.github.com/dashorst/4ee7ab1696321f290a24 shows how
> > this should be implemented.
> >
> > HOWEVER: I don't actually propose such a change, but rather have
> > adcb7a632af8225e86e09e398b8fb5430b143b18 be reverted. The linked patch
> > will break the world and for little to no benefit.
> > adcb7a632af8225e86e09e398b8fb5430b143b18 breaks API in a couple of
> > places, but I don't see the benefit of those breaks as well.
> >
> > Martijn
