How to wrap a class that has generic type methods with a class that has a generic type and no generic type arguments on the methods?

Question

I have the following code example:

class Stupid {
  private cache: Map<any, any> = new Map();
  get<T>(key: string): T {
    return this.cache.get(key);
  };
}

class Smart<T> extends Stupid {
  get(key: string): T {
    super.get<T>(key);
  }
}

I have valid reasons for wrapping the Stupid class (other than the generics) which are not apparent in this barebone reproduction of the problem, nonetheless I would like to know if this is somehow possible.

Please also note that the class Stupid is a node dependency. I can't change that implementation.

The purpose would be to not have a generic type argument on each method, but to move it to the wrapping class (class Smart) and use that in super calls, to provide the required generic to the extended class (class Stupid).

Please feel free to use this playground for experimentation.

Answer 1

The get() method in Stupid has the problematic generic call signature <T>(key: string) => T, which means that it will return a value of any type T that the caller specifies. This is demonstrably impossible:

const stupid = new Stupid();
const n = stupid.get<number>("xyz");
// const n: number
const s = stupid.get<string>("xyz");
// const s: string

In the above, you're calling stupid.get("xyz") twice at runtime, but the compiler thinks the first call returns a number and the second one returns a string, which is exceptionally unlikely. The only reason the method implementation type checks is because the return type of cache.get() is the intentionally unsafe any type.

Let's not worry too much about the type safety of Stupid.get() and instead look at the problem you're having when subclassing it:

---

class Smart<T> extends Stupid {
  get(key: string): T { // error!
    return super.get<T>(key);
  }
}

const smart: Smart<number> = new Smart();
const n = smart.get("xyz");
// const n: number

The reason that doesn't work is because subclasses must be assignable to their superclasses. If Smart<T> extends Stupid, then every Smart<T> instance is also a Stupid instance, and should be usable accordingly:

const stupid: Stupid = smart; // this should be allowed
const s = stupid.get<string>("xyz"); 
// const s: string // uh oh

Smart<number>.get() returns a number, but Stupid.get() returns any type the caller wants, such as string. These are not compatible behaviors, and so the compiler complains. If you want Smart to truly be a subclass of Stupid, you'd need to make get() generic the same way as it is in Stupid, which is not what you're trying to do.

---

So how can we proceed? Presumably we shouldn't worry too much about type safety, since there's no way to guarantee that get() returns the proper type for either Stupid or Smart. Instead we will just do what's necessary to make it compile. Usually that will require something like a type assertion to tell the compiler that some value is of some type.

Here's one way to do it:

interface Smart<T> {
  get(key: string): T
}

const FakeSmart = Stupid as new <T>() => ISmart<T>;

class Smart<T> extends FakeSmart<T> {
  get(key: string): T {
    return super.get(key);
  }
}

What we're doing is pretending that Stupid behaves like Smart. First we create an ISmart<T> interface which is the same as Stupid except that the generic is moved to where you want it. Then we assign the Stupid constructor to a new variable called FakeSmart and assert that FakeSmart has the type of a generic constructor. So FakeSmart is just Stupid at runtime, but the compiler thinks it is of a proper superclass of Smart<T>.

And then we declare that Smart<T> extends FakeSmart<T>. At runtime this is that same as your original code, but now at compile time there are no errors because the get() method of Smart<T> is compatible with the get() method of FakeSmart<T>. Note that the call super.get(key) doesn't take a type argument because FakeSmart.get() doesn't take a type argument.

---

So there you go. Personally I'd be worried about code like this where you can tell the compiler simultaneous contradictory things about the types, but if you're not the one writing Stupid then I guess the best you can do is wrap it in something more reasonable.

Playground link to code