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.vogel@xxxxxxxxx>
To:
cross-project-issues-dev@xxxxxxxxxxx,
Jeanderson Candido <jeandersonbc@xxxxxxxxx>,
Hendrik Still <Gamma32@xxxxxxxxx>
Date:
30.07.2014
11:23
Subject:
[cross-project-issues-dev]
Information
about the "Generifing JFace viewers" project
Sent
by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev