I think the JFace API is "sufficiently cool as-is" and does not need to be
made "cooler" by utilizing generics.
2014-07-30 16:46 GMT+02:00 Ed Merks <ed.me...@gmail.com>:
> Dani,
>
> As I've made pretty clear in the past, I'm a huge non-fan of this
> effort. I find it ironic that the platform is rife with raw types (List),
> and rather than investing an effort to eliminate those, effort will be
> invested on generifying things that just aren't screaming to be generified,
> and to do so in a context that is heavily dominated by Object[], which
> interacts exceedingly poorly with generics. Thought I've made that
> argument already, I think it bears repeating...
>
> Anywhere you see something like T[] where T is a type parameter, you
> already have to get suspicious. Of course we see this in
> java.util.Collection:
>
> <T> T[] toArray(T[] a);
>
> But note that T is derived from the argument, and argument my not be null,
> so even in an erased runtime environment we can determine a reasonable T
> from "a", so suspicion alleviated and that's why we can have generic
> collection implementations...
>
> Note that however nice it would have been that toArray() method looked
> like this:
>
> E[] toArray()
>
> rather than
>
> Object[] toArray
>
> because you can't implement this generically, unless you provide some
> object with the necessary *runtime *information about E to the
> constructor of an implementation class...
>
> So consider this:
>
> public interface IStructuredContentProvider extends IContentProvider {
> public Object[] getElements(Object inputElement);
> }
>
> there's no relationship between the input element's type and the type of
> the array, so if someone proposes
>
> public interface IStructuredContentProvider<X, Y> extends
> IContentProvider<X> {
> public Y[] getElements(X inputElement);
> }
>
> I'm going to be very suspicious. What this tells me is there must be some
> sensible way of being sure that I'll be getting back a real Y[] instance
> and not an Object[] instance. What could that sensible way be?
>
> Of course directly implementing that interface in a sensible way is a good
> solution, but what about generic solutions?
>
> Consider org.eclipse.jface.viewers.ArrayContentProvider (and note that EMF
> generally has *only *content provider implementations analogous to
> this). This existing implementation just don't work. You can just forget
> about org.eclipse.jface.viewers.ArrayContentProvider.instance, you can just
> deprecate org.eclipse.jface.viewers.ArrayContentProvider.getInstance(), and
> you'd better add a public constructor and deprecate it while your at it,
> because this implementation
>
> public Object[] getElements(Object inputElement) {
> if (inputElement instanceof Object[]) {
> return (Object[]) inputElement;
> }
> if (inputElement instanceof Collection) {
> return ((Collection) inputElement).toArray();
> }
> return new Object[0];
> }
>
> simply doesn't work for collections. You'll need new constructors and
> new getInstance methods each of which specify the array type, either as
> java.lang.Class or as an array prototype, as in the first form to toArray
> above. You'd have to provide that even for the constructor that takes a
> collection, just the collection instance will not suffice.
>
> Great, so much for adding generics to JFace being erasure compatible,
> counter to what was the case when Java's collection library was
> generified. Nothing in the collections library was deprecated and no new
> methods were added. In other words, for JFace's changes, you can't just
> turn off warnings about raw types, you must deal with the deprecations and
> API changes. So if you're trying to maintain something that works with old
> versions of Eclipse (i.e., EMF is compatible with Eclipse 3.5), you're
> completely hosed. You can't add generics, because you can't compile
> against an older target platform that does have it, so you simply have to
> live with a sea of raw type warnings (or turn them all off and lose the
> value of even having such warnings). Also, you can't start using the new
> methods instead of the deprecated ones, so you have to live with that sea
> of warning as well, or just turn them off too. Nor you can you exploit any
> of it to provide value to clients (given the premise there is value),
> because you can't reasonably address this ArrayContentProvider problem
> without inflicting the same pain on the clients (who actually have better
> things to do, go figure).
>
> Even the premise that this effort has value is questionable. Granted,
> someone writing their first content provider might find it useful, if (and
> only if) it's one that's concrete and if (and only if) it doesn't need to
> deal with several input types that have no common super type (and even in
> that case they'll still typically end up with instanceof tests to return
> subtype-appropriate results). That's on the argument side of the
> getElements. On the return type side, it's of no benefit to the author;
> they just pass this content provider into a generic viewer that doesn't
> care whether it's Object[] or X[]. So in fact it's just a burden with which
> one must conform.
>
> So is the value of this whole exercise eliminating instance of checks for
> the arguments of the provider implementations? Does this tangible (but
> small) benefit justify the impact on the long established community? Do we
> expect that community to eliminate their deprecations and generify all
> their code? (Sorry guys and girls, all your existing toArray() calls are
> invalid, or, don't worry about it, just sprinkle <Object, Object>
> everywhere.) I wonder, will JDT and PDE do that? If not, why expect the
> rest of the community to do it? And if you don't expect that, what exactly
> are you expecting will come from this?
>
> I suggest folks carefully weight the benefits against the disruptive
> nature of this type of change.
>
> Regards,
> Ed
>
>
>
>
> On 30/07/2014 11:42 AM, Daniel Megert wrote:
>
> Just for the records, here are some constraints that I required in order
> to agree to continue that work:
>
> - Some stuff just doesn't make sense to be generified because it often
> contains various kinds of objects, e.g. (tree) viewers. See also
> *http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html*
> <http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05459.html>.
> - If generified types cannot be plugged together unless everything is
> again just Object or Class, it's not worth to generify those types.
> - The generified code must be in a shape so that clients can start to fix
> their code by invoking Refactor > Infer Generic Type Arguments... This
> needs to be validate on existing Platform UI code.
>
> Dani
>
>
>
> From: Lars Vogel <lars.vo...@gmail.com> <lars.vo...@gmail.com>
> To: cross-project-issues-dev@eclipse.org, Jeanderson Candido
> <jeanderso...@gmail.com> <jeanderso...@gmail.com>, Hendrik Still
> <gamm...@gmail.com> <gamm...@gmail.com>
> Date: 30.07.2014 11:23
> Subject: [cross-project-issues-dev] Information about the
> "Generifing JFace viewers" project
> Sent by: cross-project-issues-dev-boun...@eclipse.org
> ------------------------------
>
>
>
> Hi,
>
> as some of you probably remember, the platform.ui team started a GSoC
> project last year to generify the JFace viewer framework. We (platform.ui
> team together with John Arthone and Dani Megert) decided that it is worth
> to finish this project and started a new GSoC project.
>
> Jeanderson Barros Candido (cc) is working on this project with Hendrik
> Still (cc) (GSoC student from last year) and me as mentor.
>
> I personally think the work looks already very good and plan to integrated
> it soon into the master. We are trying to learn from the experience from
> last year, therefore:
>
> - We plan to integrate it as a whole, not piece wise so people can fix
> warning messages created by this change
> - We reworking the JFace snippets and tests at the same time to have a
> first proof-point
> - We plan to use it for platform views to validate that it works
>
>
> Of course generifying an existing API, will result in certain limitations
> and some suggested a complete rewrite of the JFace viewer framework but
> this is currently not the scope of this project.
>
> The implementation is currently done at Github:
> *https://github.com/jeandersonbc/eclipse.platform.ui*
> <https://github.com/jeandersonbc/eclipse.platform.ui> and we do our
> planning in *https://github.com/jeandersonbc/gsoc14-eclipse-planning*
> <https://github.com/jeandersonbc/gsoc14-eclipse-planning>.
>
> If someone wants to test the new implementation and provide feedback,
> please let us know.
>
> Best regards, Lars_______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> _______________________________________________
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list,
> visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
