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

Hi Ed,

I'm deeply sorry for the missing communications. I was not aware that such things should be announced on this list.

Sorry for that.

I'm currently within a customer workshop so I look at your feedback with regards to the content tonight.

Best regards, Lars

Am 29.08.2013 09:52 schrieb "Ed Merks" <ed.merks@xxxxxxxxx>:
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 <stepper@xxxxxxxxxx>
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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top