|
There is a section in the Ecoop2002 that compares with parametric methods. To summarize:
1) Yes, variance can often be obtained by using type parameters.
2) For contra-variance, it requires 'extendedby', that is, lower-bounds. They say this domain is little studied (hum, hum).
3) Some cases cannot be expressed by variance, and need type parameters. Namely, to express type dependencies between method arguments and results.
4) To conclude, a language should have both, "to achieve even more power and expressiveness".
They illustrate this last point with a method that uses both features.
However, it turns out that you could write it with bounded type parameters only. Here is the code in Nice (changing some method names to match the JDK):
// Pair in not in the JDK, so we add it here.
abstract class Pair<A,B>
{
A getFst();
}
<X, Xminus, A, P | Xminus <: X, P <: Pair<Xminus,A> > Vector<X>
unzipleft(Vector<P> vp)
{
Vector<X> v = new Vector();
for (int i = 0; i < vp.size();i++)
v.add(i, vp.elementAt(i).getFst());
return v;
}
True, the type parameters are quite hard to read. That's where syntactic sugar comes handy (I got it right simply by applying the above desugaring to their code). But they don't show how variance adds any expressiveness. Actually, I doubt it does.
So it all really gets to point 2. If you want contra-variance (and I agree it is useful), then you need at least lower-bounds. The original GJ proposal does not have it. So they chose to add an ad-hoc extension to deal with variance. It's a reasonable choice, but I am not sure it is the best. The type system is becoming an accumulation of partially overlaping features ("because we needed them!"), which makes it more difficult to understand as a whole, and more open to fundamental errors that might go unnoticed for a while (the first GJ specification was unsound, and it took time to find it out). The more constructs you add, the more likely that some surprising interaction occurs.
It will be interesting to see if they decide to add this to Java 1.5 or not.
Personally, I prefer to start with a slighly more powerful system that has been known to be sound for a long time (7 years for ML-sub). When needed, it is always possible to add some syntactic sugar to help solving a particular, common problem, without fearing that it might break the whole type system. It was already considered to add sugar like + for method types in Nice, I suppose this proposal will make it happen faster! :-)
|
Variance in Java Generics