Re: [platform-ui-dev] Fwd: Generification of the JFace TreeViewer

[Markus Keller <markus_keller@xxxxxxxxxx>]

I didn't make a concrete proposal -- I just wanted to point out that I'd 
rather see some unchecked (but safe) casts than a big restructuring of 
viewer framework methods.

To be honest, I'm not convinced that the viewer framework should be 
generified at all. Adding generics to a framework cannot be done 
piecewise, but must be done in bigger chunks of related compilation units. 
One outcome of your project could very well be the conclusion that it's 
better not to generify most of the viewers package.

As you've already seen in StructuredViewer#refresh(Object), there are a 
few methods in the framework that can take either the input/root element 
or a child element. The StructuredViewer#getFilteredChildren(Object) 
method is another API like 'refresh' that is expected to work with any 
kind of parent element that can have children.

For flat viewers like list and table viewers, you can survive the first 
few levels of generification by declaring
        E[] getFilteredChildren(I parent)
, but this breaks down for hierarchical viewers. To obey existing API 
contracts, the 'parent' parameter of the get*Children methods must stay 
Object. It could maybe take an 'I' in list and table viewers, but not in 
general StructuredViewers.

Furthermore, for hierarchical viewers you cannot add separate type 
arguments for each level of the tree, so the gain in type safety would not 
be big for tree viewers anyway.

HTH,
Markus


Hendrik Still <hendrik.still@xxxxxxxxx> wrote on 2013-08-23 10:35:47:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thanks for the answer.
> I'm currently fixing some warnings in the code and will upload it
> later as new review.
> I'll also try to apply your suggestion.
> So your idea is to let the signature getFilteredChildren(I parent) as
> it is and cast the "elementOrTreePath" variables to I(the
> StructuredViewer expects an E) to satisfy the type system?
> I've already tested this, but I wasn't sure if this solution will
> confuse some people.
> 
> Regards,
> Hendrik
> 
> Am 22.08.2013 16:11, schrieb Markus Keller:
> > I don't have a good solution and the Gerrit link doesn't work for
> > me (page not found or no permission to view).
> > 
> > But I just wanted to point out that AbstractTreeViewer is API, and
> >  although TreeViewer is marked as @noextend, we know that many
> > clients had to extend it to solve performance problems. Therefore,
> > I'd be very reluctant to change call sequences or add more methods
> > that are overridden by subclasses.
> > 
> > It's probably better to use some unchecked casts to E to satisfy
> > the type system, but still funnel TreePath objects through methods
> > that should only operate on Es. However, this can only work as long
> > as you're sure that the erasure of such method still stays Object
> > in the signature. You have to do some real-life experiments to be
> > sure that casts in bridge methods don't hit you at run time.
> > 
> > Markus
> > 
> > Hendrik Still <hendrik.still@xxxxxxxxx> wrote on 2013-08-20
> > 15:41:12:
> > 
> >> Hi,
> >> 
> >> I'm currently adding generics support to the JFace TreeViewer,
> >> but I'm running in to some problems and I thought you could help
> >> me with that.
> >> 
> >> Unlike the other Viewers, with flat data structures like the 
> >> TableViewer, the TreeViewer has to handle (of course) tree like
> >> data structures.
> >> 
> >> For the viewers in general we decided to have two type parameters
> >> for every viewer. E for an single element the viewer should
> >> display and I for the input you set with the setInput method. For
> >> example you are able to type a TableViewer with
> >> TrableViewer<Person,MyOwnListOfPersons> This type parameters are
> >> also applicable to the TreeViewer, but the tree structure and the
> >> internal implementation of the viewer does not allow a stronger
> >> typing of method parameters like it is done in the other
> >> viewers.
> >> 
> >> For example the method isExpandable(Object elementOrTreePath) in
> >> the AbstractTreeViewer class. This method handles elements (typed
> >> as E), the input (typed as I) and additional to that a
> >> TreePath(typed as TreePath) for the ITreePathContentProvider. The
> >> handling for the different types are managed at runtime. Also
> >> this works fine with generics, the problem is the call of the
> >> getFilteredChildren(I parent) method from the
> >> superclass(StructuredViewer). The getFilteredChildren method is
> >> not only called with as I typed parameters, but also with E and
> >> TreePath typed parameters. The signature of the 
> >> getFilteredChildren method is correct for all viewers, except
> >> for TreeViewer.
> >> 
> >> After consulting my mentor Lars Vogel, my first try was to
> >> override the getFilteredChildren method in the AbstractTreeViewer
> >> class with the signature getFilteredChildren(Object parent),
> >> which called the getRawChildren method of the AbstractTreeViewer.
> >> But to still execute the filters which could not be accessed from
> >> the AbstractTreeViewer, I had to outsource the filter 
> >> functionality to another protected method (internalFilter) which
> >> can be called from the subclass.
> >> 
> >> You can see my currently running changes at 
> >> https://git.eclipse.org/r/#/c/15647/
> >> 
> >> So what do you think? Is this a acceptable solution for the
> >> issue?
> >> 
> >> Regards, Hendrik
> > 
> > _______________________________________________ platform-ui-dev
> > mailing list platform-ui-dev@xxxxxxxxxxx 
> > https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
> > 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJSFx7jAAoJECjZOs4dIxisv0wH/2cY5KE9hDfC3ViBEInhrLmO
> PIdWEtn13o8bnU4ZpPv0UeGgj/kuLDLP/MB6JDT7yCKDK1Dsvx67tyjqEQbP54eQ
> RPosJIqv9W3eF2cO7th9cA+8MoslLKEIgOE0SfQJWkJoFDq8nmiolVsvirnpbTli
> YbmJ1sQyBjz6I0qrYpOYXrrKHRsITSNh9ic+Af4JVCBUJYCC0TCnCCUA+04GMBjW
> hnJxUPTLkPSU08/ZBumyyV8z9mP6DB0NGDP49t7IYjRfg/rLJSoTFf2rKLg1ky69
> W26g1jlf7iG8mrDeV+cGHxwskyX2jmO3eRZ4wJ1teyizLUTba15n0ZvyMIU7E5c=
> =ik/p
> -----END PGP SIGNATURE-----
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>