Markus,
Comments below.
On 30/07/2014 7:18 PM, Markus Keller
wrote:
Hi Ed
Thanks for this excellent
write-up of
https://bugs.eclipse.org/416189
!
Yes, the proposed changes will be
scrutinized,
and it's very well possible that the outcome is again WONTFIX.
Side-note about
java.util.Collection's
<T> T[] toArray(T[] a): That method looks type-safe, but
it's not.
Well, yes and no. It's guaranteed (at least by
contract) to return an array of T, i.e., an array of the same type
as "a". It doesn't requires that T have any relation to E, so
yes, trying to store each E instance of the Collection into "a" or
its clone if "a" isn't big enough can result in an array
store exception. Of course the exact same statement was true
before they generified it.
Again, there's no
connection between the Collection's <E> and the
method's <T>.
Indeed.
See its @throws
ArrayStoreException and the example
in https://bugs.openjdk.java.net/browse/JDK-7023484
But the point is, its guaranteed to produce T[], and it's able to do
so in any Collection implementation. As we all know from writing
c.toArray(new X[c.size()]) again and again, it would have been
totally convenient if toArray return E[], but it doesn't though it
certainly could, if each collection constructor required an X[]
prototype or an X.class instance. So while incredibly convenient
for calling toArray, and very convenient for fail fast type safety
even in contexts that have erased the type, that's not what they
decided to do.
Markus
From:
Ed Merks
<ed.merks@xxxxxxxxx>
To:
cross-project-issues-dev@xxxxxxxxxxx
Date:
2014-07-30 16:47
Subject:
Re:
[cross-project-issues-dev]
Information about the "Generifing JFace viewers"
project
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
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
_______________________________________________
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
|