Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] JFace Generics

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
My blog - My Tweets

Back to the top