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:
Hello,
as part of my Google Summer of Code Project I'm currently responsible
for the changes in the JFace Viewers, which leads to your warnings.
I fully understand your concerns about the incomplete generification
of the viewer classes. We intended to have small reviews, but I agree
that merging this changes to the master was not the best idea.
I'll talk to Lars and John and suggest to roll the changes back and
work in a own branch.
I also will discuss with my mentors how to proceed with this project.
I'm also deeply sorry for the missing communication and the trouble.
Regards,
Hendrik
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev