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,
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.
Best regards, Lars
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|