Florian Brunner wrote:
So, 2 votes for option 3), which is a reasonable one, I think.
Pavel? Anyone else?
There certainly are cases when it's tempting to use a String as a
prototype value for a more complex object. However, with #3 this is
still doable in a number of ways: JList<Object>, raw JList, or use
setFixedCellW/H() instead.
I like #3 most.
2009/2/21 Florian Brunner <fbrunnerl...@gmx.ch>
So I think we have 3 options:
1) Don't provide a generic cell renderer/ allow only Object as parameter
for the cell renderer in
JList.
2) Add a second generic parameter. Eg. something like:
class JList <E, P super E>{ ... }
and use P for the prototypeCellValue property as well as for the cell
renderer.
3) Require prototypeCellValue to be of type E. In the probably rare
cases, where this is a problem
one can still specify a common base class of the items and the
prototypeCellValue as the generic
parameter or use a raw type JList.
I think it would be a pity not to provide a generic cell renderer (1) and
think 2) is inconvenient
and confusing, since in my experiences prototypeCellValue is only used
rarely.
So I'm voting for 3). For which option do you vote? For which reason?
--
Peter | x33066 | location: SPB04 | timezone: GMT+03
