The overload signature does not align with the implementation signature when working with subclasses

Question

The overload signature does not align with the implementation signature when working with subclasses

Uncertain whether it's a typescript bug or an error in my code. I've been working on a plugin that generates code, but upon generation, I encounter the issue

This overload signature is not compatible with its implementation signature

in the resulting file.

A simple reproducible example is provided below. It seems like the error surfaces when any variable is added to one of the extending classes. In this scenario, removing protected anything = 'test'; eliminates the error.

abstract class GraphtonBaseReturnTypeBuilder {

    public withRelated(relatedType: string, buildFields: (r: GraphtonBaseReturnTypeBuilder) => void): this {
        return this;
    }
}

type UserReturnTypeObjectField = "posts"|"friends";

class UserReturnTypeBuilder extends GraphtonBaseReturnTypeBuilder {
    protected anything = 'test';
    
    public withRelated(relatedType: "posts", buildFields: (r: PostReturnTypeBuilder) => void): this;
    //     ~~~~~~~~~~~ This overload signature is not compatible with its implementation signature
    public withRelated(relatedType: "friends", buildFields: (r: UserReturnTypeBuilder) => void): this;
    public withRelated(relatedType: UserReturnTypeObjectField, buildFields: (r: GraphtonBaseReturnTypeBuilder) => void): this {
        return super.withRelated(relatedType, buildFields);
    }
}

type PostReturnTypeObjectField = "author"|"repatedPosts";

class PostReturnTypeBuilder extends GraphtonBaseReturnTypeBuilder {

    public withRelated(relatedType: "author", buildFields: (r: UserReturnTypeBuilder) => void): this;
    //     ~~~~~~~~~~~ This overload signature is not compatible with its implementation signature
    public withRelated(relatedType: "repatedPosts", buildFields: (r: PostReturnTypeBuilder) => void): this;
    public withRelated(relatedType: PostReturnTypeObjectField, buildFields: (r: GraphtonBaseReturnTypeBuilder) => void): this {
        return super.withRelated(relatedType, buildFields);
    }
}

The complete file can be found on github: https://github.com/GraphtonLib/Graphton/blob/main/example/graphton.generated.ts

The problematic lines are located at line 229 and line 259

Full error details:

example/graphton.generated.ts:229:12 - error TS2394: This overload signature is not compatible with its implementation signature.

     public withRelated(relatedType: "posts", buildFields: (r: PostReturnTypeBuilder) => void): this;
               ~~~~~~~~~~~

  example/graphton.generated.ts:231:12
    231     public withRelated(relatedType: UserReturnTypeObjectField, buildFields: (r: GraphtonBaseReturnTypeBuilder) => void): this {
                   ~~~~~~~~~~~
    The implementation signature is declared here.

example/graphton.generated.ts:259:12 - error TS2394: This overload signature is not compatible with its implementation signature.

259     public withRelated(relatedType: "author", buildFields: (r: UserReturnTypeBuilder) => void): this;
               ~~~~~~~~~~~

  example/graphton.generated.ts:261:12
    261     public withRelated(relatedType: PostReturnTypeObjectField, buildFields: (r: GraphtonBaseReturnTypeBuilder) => void): this {
                   ~~~~~~~~~~~
    The implementation signature is declared here.

typescript

Answer 1

Answer №1

The main issue with the task at hand is its lack of type safety. This superclass

abstract class GraphtonBaseReturnTypeBuilder {    
    public withRelated(
      relatedType: string, 
      buildFields: (r: GraphtonBaseReturnTypeBuilder) => void
    ): this {
        return this;
    }
}

defines a GraphtonBaseReturnTypeBuilder with a withRelated() method that takes any string as the first argument and a callback function that must accept any GraphtonBaseReturnTypeBuilder as the second argument. Therefore, it allows for scenarios such as:

function process(g: GraphtonBaseReturnTypeBuilder) {
    g.withRelated("randomString", g => console.log(g)); // valid
}

When you create a UserReturnTypeBuilder class that extends GraphtonBaseReturnTypeBuilder, type safety requires the UserReturnTypeBuilder to be able to perform all actions of its parent class and be used in place of it, adhering to the substitutability principle.

This also means that:

process(new UserReturnTypeBuilder()); // acceptable

If UserReturnTypeBuilder overrides the withRelated() method, it should only accept arguments equal to or broader than those expected by the overridden method. For instance, if the superclass accepts any string for relatedType, the subclass should not restrict it further but can broaden it (e.g., string | number), following the concept of method parameter bivariance.

class UserReturnTypeBuilder extends GraphtonBaseReturnTypeBuilder {
  protected anything = 'test';

  public withRelated(
    relatedType: "posts", 
    buildFields: (r: PostReturnTypeBuilder) => void
  ): this;
  public withRelated(
    relatedType: "friends", 
    buildFields: (r: UserReturnTypeBuilder) => void
  ): this;

  public withRelated(
    relatedType: UserReturnTypeObjectField, 
    buildFields: (r: any) => void
  ): this {
      return super.withRelated(relatedType, buildFields);
  }
}

It's important to ensure compatibility between implementation signatures and call signatures when using function overloads. The expectation is for the implementation to include all possible variations seen in the calls, ensuring wider acceptance criteria or at least an equally wide scope.

Your previous signature

(r: GraphtonBaseReturnTypeBuilder) => void)

does not align with these principles. Using more inclusive types like (r: any) => void might be necessary when prioritizing flexibility over strict type safety.

To prioritize type safety, consider making the common parameters generic within a base class:

abstract class GraphtonBaseReturnTypeBuilder<RF extends Record<keyof RF, unknown>> {
    public withRelated<K extends keyof RF>(
      relatedType: K, buildFields: (r: RF[K]) => void): this {
        return this;
    }
}

Subclasses like UserReturnTypeBuilder and PostReturnTypeBuilder can then refine these generics to tailor instances specific to their needs, ensuring stricter parameter validation and minimizing undesired scenarios like passing arbitrary strings.

Aim for a design where each GraphtonBaseReturnTypeBuilder instance has a defined set of related fields, enforcing stronger typing constraints throughout your codebase.

Playground link to explore further

Answer 2

The main issue with the task at hand is its lack of type safety. This superclass

abstract class GraphtonBaseReturnTypeBuilder {    
    public withRelated(
      relatedType: string, 
      buildFields: (r: GraphtonBaseReturnTypeBuilder) => void
    ): this {
        return this;
    }
}

defines a GraphtonBaseReturnTypeBuilder with a withRelated() method that takes any string as the first argument and a callback function that must accept any GraphtonBaseReturnTypeBuilder as the second argument. Therefore, it allows for scenarios such as:

function process(g: GraphtonBaseReturnTypeBuilder) {
    g.withRelated("randomString", g => console.log(g)); // valid
}

When you create a UserReturnTypeBuilder class that extends GraphtonBaseReturnTypeBuilder, type safety requires the UserReturnTypeBuilder to be able to perform all actions of its parent class and be used in place of it, adhering to the substitutability principle.

This also means that:

process(new UserReturnTypeBuilder()); // acceptable

If UserReturnTypeBuilder overrides the withRelated() method, it should only accept arguments equal to or broader than those expected by the overridden method. For instance, if the superclass accepts any string for relatedType, the subclass should not restrict it further but can broaden it (e.g., string | number), following the concept of method parameter bivariance.

class UserReturnTypeBuilder extends GraphtonBaseReturnTypeBuilder {
  protected anything = 'test';

  public withRelated(
    relatedType: "posts", 
    buildFields: (r: PostReturnTypeBuilder) => void
  ): this;
  public withRelated(
    relatedType: "friends", 
    buildFields: (r: UserReturnTypeBuilder) => void
  ): this;

  public withRelated(
    relatedType: UserReturnTypeObjectField, 
    buildFields: (r: any) => void
  ): this {
      return super.withRelated(relatedType, buildFields);
  }
}

It's important to ensure compatibility between implementation signatures and call signatures when using function overloads. The expectation is for the implementation to include all possible variations seen in the calls, ensuring wider acceptance criteria or at least an equally wide scope.

Your previous signature

(r: GraphtonBaseReturnTypeBuilder) => void)

does not align with these principles. Using more inclusive types like (r: any) => void might be necessary when prioritizing flexibility over strict type safety.

To prioritize type safety, consider making the common parameters generic within a base class:

abstract class GraphtonBaseReturnTypeBuilder<RF extends Record<keyof RF, unknown>> {
    public withRelated<K extends keyof RF>(
      relatedType: K, buildFields: (r: RF[K]) => void): this {
        return this;
    }
}

Subclasses like UserReturnTypeBuilder and PostReturnTypeBuilder can then refine these generics to tailor instances specific to their needs, ensuring stricter parameter validation and minimizing undesired scenarios like passing arbitrary strings.

Aim for a design where each GraphtonBaseReturnTypeBuilder instance has a defined set of related fields, enforcing stronger typing constraints throughout your codebase.

Playground link to explore further

The overload signature does not align with the implementation signature when working with subclasses

Answer №1

Similar questions

Angular 2 - Dragula for ng2

Is it feasible to set an empty object as the initial default value in the state of a React component?

Why did the homepage load faster than the app.component.ts file?

I am currently struggling with a Typescript issue that I have consulted with several individuals about. While many have found a solution by upgrading their version, unfortunately, it

Tips for ensuring proper dependency regulations in javascript/typescript/webpack

Ensuring type signatures are maintained when wrapping Vue computed properties and methods within the Vue.extend constructor

Tips for running batch files prior to debugging in VS Code

Refreshing the cache in SWR, but the user interface remains unchanged inexplicably - SWR hook in Next.js with TypeScript

Tips for simulating the getCustomRepository function in typeORM

Deriving data types based on a variable in TypeScript

Creating a custom React hook in TypeScript to handle mouse events

Select a random class from an array of classes in JavaScript

Having trouble using the 'in' operator to search for 'Symbol(StrapiCustomCoreController)' while transitioning Strapi to TypeScript

The ValidationSchema Type in ObjectSchema Seems to Be Failing

Nested formArrays within formArrays in Angular 4

Splitting a string in Typescript based on regex group that identifies digits from the end

Guidelines on incorporating emotion/styled into React applications with TypeScript

What steps should be followed to effectively incorporate Google Fonts into a Material UI custom theme for typography in a React/TypeScript project

What is the correct way to declare the mongoose _id in a TypeScript interface?

Issue with 'else if' statement in React Typescript: Unneeded 'else' block following 'return' statement