Hi Ed
As opposed to last year, where it was generified piece by piece, I this
time expect the final result being presented to the community in a topic
branch, including some Platform UI code being converted to show the added
value. The community will then have to scrutinize it and we will then
decide whether this really improves JFace and makes it easier to use, or
whether we live with what we have.
Dani
From: Ed Merks <ed.me...@gmail.com>
To: cross-project-issues-dev@eclipse.org
Date: 30.07.2014 16:47
Subject: Re: [cross-project-issues-dev] Information about the
"Generifing JFace viewers" project
Sent by: cross-project-issues-dev-boun...@eclipse.org
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.
- 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>
To: cross-project-issues-dev@eclipse.org, Jeanderson Candido
<jeanderso...@gmail.com>, Hendrik Still <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 and we do our planning
in 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 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
_______________________________________________
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
