tags:

views:

59

answers:

1

I have an interface parametrized on a type which extends a parametrized type, and that interface contains a method which needs the type parameter of the type being extended. In code, this is what I want:

class Thingy<X> { ... }

interface Foo<P extends Thingy<?>> {
  <T> T frobnicate(P<T> a);
}

But that doesn't compile. In order to properly frobnicate a Thingy, it's necessary to know the type of Thingy it is, but also some Foos may be specialized for handling only particular kinds of Thingys (the exception being that they are required to be able to handle whatever type T any Thingy is parametrized on).

(BTW, I've already spotted these questions. The former is about requiring only one generic parameter; I don't care if I need one, two, or five here, so long as there's some solution. The latter has a specific type rather than a wildcard in the class corresponding to my Foo, so the solution there isn't applicable here, so far as I can see.)

EDIT:

Since the number of subclasses of Thingy I intend to have is small, I can get the same effect by subclassing Thingy and creating another interface just for handling those:

interface Foo {
  <T> T frobnicate(Thingy<T> a);
}

class SpecialThingy<T> extends Thingy<T> { ... }

interface Bar {
   <T> T frobnicate(SpecialThingy<T> a);
}

That's not as elegant as I would have liked, but it will do the job in this case.

+2  A: 

Instead of using a type parameter which extends Thingy<T>, use a type parameter for just the T and add the Thingy part to where it is needed:

class Thingy<X> { }

interface Foo<X> {
  X frobnicate(Thingy<X> a);
}

Or if you need to use a specific subclass of Thingy, then how about this?

class Thingy<X> { }

interface Foo<X, T extends Thingy<X>> {
  X frobnicate(T a);
}

If you require something more complex, then the simplest thing would be to just have runtime type checks. Sometimes generics produce more unnecessary complexity than they are worth.

It's also possible that with a better design you could avoid the need for expressing such things with generics. To give suggestions about that, it would be necessary to know more about how the Thingies are used and have a more concrete example than Thingies and Foos.

EDIT:

Since the requirement is that Thingy's type paramerer can not be known beforehand, then this should be the only option:

interface Foo {
  <T> T frobnicate(Thingy<T> a);
}

Follow the Liskov substitution principle and make it work for all implementations of Thingy. If the code can work only for some subtypes of Thingy, then I don't think that you can express it with generics (it would require giving type parameter for a type parameter), and the only option is to have runtime type checks. And runtime type checks are a code smell, so it's best to fix the design so that it's not needed.

Esko Luontola
Your examples miss one of my requirements, which is that a `Foo` can't know in advance what parameter any `Thingy` is sees will have.
uckelman
Answer updated.
Esko Luontola