|Re: [cross-project-issues-dev] Information about the "Generifing JFace viewers" project|
Regarding “Side-note about java.util.Collection's <T> T toArray(T a): That method looks type-safe, but it's not.” and “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. ”
It really isn’t guaranteed to produce a T. An example:
Here T is Serializable all the way (I explicitly say so!) but thanks to String also being Serializable an assignment from String to Serializable is allowed. However the element type of the returned array is still String at runtime and not the T. Generics and arrays just don’t match.
Regarding “So we'd need to all switch to Java 8 and our code would become a sea of deprecation and raw type warnings.”
That’s what happens with Objects and raw types being passed around. You could also change existing methods to use strong types which would break APIs but on the plus side get rid of @Deprecated and @SuppressWarnings annotations littering the code.
Regarding “So do the above look simple than the current code? Was it easier to write? Did generics provide value or make it more complex without providing value? It's clear It's not simple and generics actually made it more complicated.
No only that, but as I've pointed out, the convenience to the author is generics on the argument side of the equation, not on the return type side.”
Well, this is how a strongly-typed IStructuredContentProvider might look like in part:
And a similarly strongly-typed ArrayContentProvider closely mimicking the original (here using a Pair-helper class):
Using a Pair or a Tuple class in this manner is ugly. An improvement would be to split that into two classes, an ArrayContentProvider and a CollectionContentProvider:
If everything was this strongly-typed then these classes are actually almost useless. The callers could just as well call Collections.unmodifiableList(Arrays.asList(inputElement)) and
Collections.unmodifiableList(new ArrayList<>(inputElement)) themselves.
This would be the best-case scenario and is unlikely to happen, but with generics it could. So if you don’t see a clear benefit from generics, add more generics!
Have a nice day,
Sent from Windows Mail
On 30/07/2014 7:19 PM, Timo Kinnunen wrote:
So we'd need to all switch to Java 8 and our code would become a sea of deprecation and raw type warnings.
Of course you'd propose Collection<? extends T> or List<? extends T> not ArrayList, right?
So you're suggesting that no one should ever use or implement this method. While that's certainly a way to avoid the whole problem with generic array, none of this fits with Dani's "the problems should go way just by inferring types".
So do the above look simple than the current code? Was it easier to write? Did generics provide value or make it more complex without providing value? It's clear It's not simple and generics actually made it more complicated.
No only that, but as I've pointed out, the convenience to the author is generics on the argument side of the equation, not on the return type side.
The real question is, was it easier to write? Because in the end, who are the callers to these APIs? A bunch of generic viewers that are already written and that we don't generally write ourselves. And they don't care currently. So the whole things fundamentally has to come down to what's easiest for the authors to write content providers.
Yes, it's certainly far more reasonable to argue getting rid of the arrays. But that's even more fundamentally disruptive, and requires Java 8. Note that EMF heavily uses Collection<?> rather than Object in its platform neutral equivalents of these APIs.
I think that makes no sense. The client must always create a specific list implementation and the contract allows the caller to add instances to that collection? Collection<? extends T> would seem far more reasonable and convenient. Then one could return just the collection you already have or use Arrays.asList.
Back to the top