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
|