Hi,
It's difficult to avoid an emotional outburst at this type of thing.
I'm completely shocked that sweeping changes of this nature go
unannounced on this mailing list. Sorry, a blog doesn't cut it...
It's clear the current state is woefully incomplete. I.e., we have
IStructuredContentProvider<E, I> but ITreeContentProvider is still
raw. Of course it's clear that a tree rarely has uniformly typed
children, so what is the plan for the completion of JFace's APIs? I
question all this being committed to master in incremental stages like
this...
EMF is a sea of warnings with these changes, and eliminating those is
weeks of work; work I can't begin because the changes are incomplete.
And of course this affects all users of JFace, not just EMF, so the
overall impact to the community is hard to calculate. The most
disturbing part of all this is that I question whether it has even been
well thought out. For example, the following change is highly disturbing:
public interface IStructuredContentProvider<E,I> extends
IContentProvider<I> {
public E[] getElements(I inputElement);
}
Suppose I used it like this:
public class GenericContentProvider<E, I extends List<E>>
implements IStructuredContentProvider<E, I> {
@Override
public void dispose() {
}
@Override
public void inputChanged(Viewer<I> viewer, I oldInput, I
newInput) {
}
@Override
public E[] getElements(I inputElement) {
return (E[])inputElement.toArray();
}
}
I.e., I have a generic content provider implementation class that for a
List<E> input returns the elements of that list. But there is a warning
in the code for "E[])inputElement.toArray();" and it's not something one
can blithely ignore. It will *never *be possible to create a generic
subclass of IContentProvider that leaves E unsubstituted by a concrete
implementation class, because it will never be possible to create an E[]
array. If you question this assertion, stop and ask yourself why
java.util.Collection.toArray() if of type Object[] and not of type E[]?
It's because it would not be possible to implement generic Collection
implementation classes.
I can't emphasize enough how disturbing I find the approach being taken
here. We're all familiar with using generics, but implementing generic
classes properly remains complex and tricky and what's being done in
JFace doesn't just impact the use of generics, it forces us all to
revisit our implementation classes. For example, perhaps someone can
explain how org.eclipse.jface.viewers.ArrayContentProvider will be
updated? Probably just to "class ArrayContentProvider implements
IStructuredContentProvider<Object, Object>" I would imagine, but that's
not terribly useful is it? I imagine the overall impact on the
community is to make sweeping pointless changes of precisely this
nature. But suppose I even have a nice implementation class where I
wanted IStructuredContentProvider<Foo, Bar>, my current implementation
of getElements is probably wrong and would need to change to return
Foo[]. But of what value is that? ContentProviders are generally just
passed to a generic viewer, which uses it in a context where the types
don't matter. So what's the benefit?
Sorry to be so extreme in my opinion, but I would go further and argue
that it's hard to imagine a significant set of scenarios where the new
APIs are helpful even if this generic array issue wasn't just plain
wrong or a horribly bad idea... I could go on and on, but as I said,
it's hard to remain unemotional about this...
Regards,
Ed
On 29/08/2013 7:46 AM, Lars Vogel wrote:
Hi Eike,
this is a GSoC done by Hendrik (cc) and was announced on
PlanetEclipse. See
http://blog.vogella.com/2013/06/17/google-summer-of-code-at-eclipse-2/. John
Arthone and I are the mentors for this project
The work is still ongoing so far the ComboViewer and the TableViewer
have been converted as well several basic classes. We currently don't
know if we can generify IStructuredSelection.
Input is very welcome, the umbrella bug is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=402445 and every code
change is pushed to Gerrit. Look in
https://git.eclipse.org/r/#/q/platform/eclipse.platform.ui,n,z for
Hendrik (so don't know how to narrow the query down to Hendrik only).
Best regards, Lars
2013/8/29 Eike Stepper <[email protected] <mailto:[email protected]>>
Hi,
After updating my target platform to Luna I noticed that my
workspace is full of raw type warnings caused by changes in JFace
to generify its APIs, for example Viewer. But the changes look
incomplete, e.g., ViewerDropAdapter.getViewer() is still a raw
type. Can we expect more such changes, e.g., IStructuredSelection?
Has there been an announcement for these changes? Is there any
advice on how to adjust our code?
What about other Eclipse APIs, such as
IAdaptable.getAdapter(Class), will it be changed to <T> T
getAdapter(Class<T>)?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[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
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
