Re: Mixing self conscious parametrized types with inheritance

Robert Klemme wrote:


People will have to review the thread if they want the part I elided.

I think the problem is that the base class is 'implements Comparable <S>'.
That really isn't the type assertion for 'Comparable'. The
self-referentiality is tangling the type assertions, for sure, but the real
problem is that you want the subclass to implement its own 'compareTo()'
separate from the superclass's. The wildcard dodge weakens the type
assertions to the point where you get away with it.

Normally a comparable class 'Foo' uses 'implements Comparable<Foo>'. You
didn't do that. If you had, you'd wind up with:

  class BaseC<SC extends BaseC<?>> implements Comparable<BaseC<SC>> {
   @Override
   public int compareTo( BaseC<SC> o) {
     return getKey() - o.getKey();
   }
  }

You cheated by having 'BaseC#compareTo()' take a different type argument from
what it's supposed to take. Yes, you did subvert the generics system by doing
that, but only by changing the semantics of what you're asserting.

Then you'd have

  class SubC<SC extends SubC<?>> extends BaseC<SC> {
   @Override
   public int compareTo( SubC<SC> o) {
     final int cmp = getK() % 3 - o.getK() % 3;
     return cmp == 0 ? getK() - o.getK() : cmp;
   }
  }

which yields the correct compiler error that you had subverted, with or
without a clause 'implements Comparable<SubC<SC>>'.

I also wonder about the 'extends BaseC<SC>' part. Generics aren't covariant
through the type parameter without some 'extends' magic, so I think this part
tangles the type assertions also. I haven't thought it through yet.

Anyway, you have found a corner where the generics assertions cannot handle
what you wanted to do. That part is true. It is also true that formally you
want to make different type assertions from those to properly implement
'Comparable'. When you make the correct type assertions, the compiler chokes
on the erasure demon.

You might be able to get away with the kind of self-referentiality you want
better with interfaces at the root than with classes. That's a good followup
line of inquiry.

--
Lew
Honi soit qui mal y pense.