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).
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
