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.me...@gmail.com>:
> 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 <step...@esc-net.de>
>
>> 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@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing
> listcross-project-issues-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
