| Re: [cross-project-issues-dev] JFace Generics |
|
Hendrik, Yes, I think reverting the changes would be best. Thanks for your understanding. Not to rain on anyone's parade, but respectfully suggest the platform team should reconsider the gain verses the client impact for generifying the JFace APIs. Designing generic containers isn't easy, and it's all too easy to make mistakes that will be difficult to correct in the future. Looking at the overall changes, I see that little regard is given to the subtleties of Foo<E> verses Foo<? extends E>, e.g., the following method, should really use List<? extends E> because it doesn't modify the argument and callers should be allowed to pass in any list that's guaranteed to contain elements of type E, even if they're restricted to containing only elements that are subtypes of E. org.eclipse.jface.viewers.StructuredViewer.setSelectionToWidget(List<E>, boolean)This subtle problem is rife in the code, e.g., is this really correct? org.eclipse.jface.viewers.ContentViewer.setContentProvider(IContentProvider<I>)Or should it be IContentProvider<? extends I>? I see (in Gerrit; thanks Matthias) that you've committed changes for TreeViewer and here I think the whole approach is completely questionable. When is it the case that a tree view has uniformly the same elements throughout? I think that's so rarely the case that it's worse than useless to make such an assumption; I would argue it's mostly just noise that will never solve real problems. In the end, many of the things being changed are effectively SPI. One implements the APIs for providers and passes them to a generic container that does the right things with it. There's little to be gained from adding generics, to justify the cost to the ecosystem, and getting it right is much harder than it appears at first glance... Regards, Ed On 29/08/2013 12:36 PM, Hendrik Still
wrote:
|