You're right when saying that ITreeContentProvider seems indeed to
be the place where generics don't provide much value. But generic in
a viewer in general can help, especially when it comes to
implementing the LabelProvider. Most of the EMF-based use-case I've
seen introduce a kind of Labeled type which contains common stuff
(id, label, comment...). It would be nice if I could tell my Viewer
that all contents will actually be Labeled objects and avoid some
(useful or useless) casts written by the developer because of the
fact he was not sure of what's exactly in the TreeViewer.
For other "raw" viewers (ListViewer, TableViewer, ComboViewer...)
where all items are generally of the same Type such generics seem
totally relevant to me. WDYT?
I totally agree with you that this change is difficult and should be
implemented perfectly and that is has to be fully backward
compatible. And I am not against any technical debate on how to
implement this the best.
However, when it comes to warnings, here is how I understand your
comment: "I don't want this change because I've made efforts to get
no warnings, and this improvement will now show warnings on my
code". So it means that legacy consumer projects have to slow down
improvement on "core" projects?
Now that there is/will be generics on Viewers, you'll see a bunch of
new warnings, but it doesn't mean that EMF is worse and it doesn't
put EMF at risk. You'll have the choice: either keep this warnings
visible, or hide those warnings, or fix them. None of those
solutions makes EMF or any project worse (but the 3rd one make it
better).
|