question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

TS Proposal : "Interface incorrectly extends interface" - sub-interface method overload OR override ?

See original GitHub issue

TypeScript Version : 2.6.2

The problem

Initial scenario

I encountered the issue yesterday days as I was trying to add some features to one of my interface inheritance chain. The context of this example is just imagined : It is longer than needed to demonstrate the issue, but I wanted a full example to clearly show it needs to be addressed.

So, let’s imagine a testing app that should instrument devices : the following is a potential model of the situation :

interface Stream
{
}
interface InputStream
{
}
interface OutputStream
{
}
// interface inheraitance is a great feature
interface IOStream extends InputStream, OutputStream
{
}
interface InterfaceLike
{
}
interface DeviceInterfaceLike extends InterfaceLike
{
    init();
}
interface InputDeviceInterfaceLike extends DeviceInterfaceLike
{
    input(); // this should word just like the `touch` command
             //     like if there's and error with the device, it will trigger exception
    input(stream: InputStream);
}
interface ScreenDeviceInterfaceLike extends InputDeviceInterfaceLike
{
    input(stream: InputStream, coordinates: {x: number, y: number});
}
interface TouchScreenDeviceInterfaceLike extends InputDeviceInterfaceLike
{
    input(stream: IOStream, coordinates: {x: number, y: number});
}

Expected behavior :

It should just overload that method in the sub-interfaces.

Actual behavior :

error TS2430: Interface 'ScreenDeviceInterfaceLike' incorrectly extends interface 'InputDeviceInterfaceLike'.
  Types of property 'input' are incompatible.
    Type '(stream: InputStream, coordinates: { x: number; y: number; }) => any' is not assignable to type '{ (): any; (stream: InputStream): any; }'.
core.ts(73,11): error TS2430: Interface 'TouchScreenDeviceInterfaceLike' incorrectly extends interface 'InputDeviceInterfaceLike'.
  Types of property 'input' are incompatible.
    Type '(stream: IOStream, coordinates: { x: number; y: number; }) => any' is not assignable to type '{ (): any; (stream: InputStream): any; }'.
18:38:26 - Compilation complete. Watching for file changes.

It requires me to fully copy paste all method signatures in each interface.

interface ScreenDeviceInterfaceLike extends InputDeviceInterfaceLike
{
    input(); // this should word just like the `touch` command
             //     like if there's and error with the device, it will trigger exception
    input(stream: InputStream);
    input(stream: InputStream, coordinates: {x: number, y: number});
}
interface TouchScreenDeviceInterfaceLike extends InputDeviceInterfaceLike
{
    input(); // this should word just like the `touch` command
             //     like if there's and error with the device, it will trigger exception
    input(stream: InputStream);
    input(stream: IOStream, coordinates: {x: number, y: number});
} 

When you’re can have up to (why not) 15 overloads distributed through inheritance chain… It becomes, (yes, you said it) bulky.


Now it is, that the compiler cannot yet figure out when to override the method signatures inherited from parents and when to overload them.

The Proposal

My first thought was to introduce a new keyword just like @ts-nocheck and like.

@override

interface InputDeviceInterfaceLike extends DeviceInterfaceLike
{
    @override // to override all definitions from parents
    init(istream: InputStream);
}

OR

interface InputDeviceInterfaceLike extends DeviceInterfaceLike
{
    @override
    {
        init(); // to override only this (these) definitions : forget all previous definition but this (these)
    }
    init(istream: InputStream);
}

Then, the TouchScreenDeviceInterfaceLike interface would become :

interface TouchScreenDeviceInterfaceLike extends InputDeviceInterfaceLike
{
    @override   // it is now clear that the only way to instrument a touchscreen is to provide a `IOStream` and coordinates (`{x: number, y: number}`)
    input(stream: IOStream, coordinates: {x: number, y: number});
}

Furthermore, @overload

While the previous @override is useful when the default behavior is oveloading, we can still define the default behavior to suppress all parent definition WHEN A METHOD IS REDEFINED in subinterface, except when @overload is used. i.e

interface InputDeviceInterfaceLike extends DeviceInterfaceLike
{
    // to override all definitions from parents
    init(istream: InputStream);
}

OR

interface InputDeviceInterfaceLike extends DeviceInterfaceLike
{
    @overload // to overload signatures from parents
    init(istream: InputStream);
}

And TouchScreenDeviceInterfaceLike interface can become :

interface TouchScreenDeviceInterfaceLike extends InputDeviceInterfaceLike
{
    @overload                           // to overload signatures from parents
    {
        init(istream: InputStream);     //      except this signature... So that it remains only the empty parameter and the below
    }
    input(stream: IOStream, coordinates: {x: number, y: number});
}

By thinking rigorously, I think the first step would be allow inheriting type to overload methods by default.

= = = = = = UPDATE = = = = = = I now think it worth to add that by no mean, all through an interface inheritance chain should a method be completely wiped off (deleted, removed)… Not even by @Override! As this may (will) break the core concept of OOP inheritance.

The mechanism is to ensure that only some methods mood (signatures) are handled (accepted) at a given inheritance node.

In other words, if @Override suppresses all signatures, at least one method signature MUST be required.

Issue Analytics

  • State:open
  • Created 6 years ago
  • Reactions:25
  • Comments:6 (1 by maintainers)

github_iconTop GitHub Comments

15reactions
zhengxiaoyao0716commented, Sep 19, 2019

Maybe we can just using an custom type to resolve it:

type ProtoExntends<T, U> = U & {
  [P in Exclude<keyof T, keyof U>]: T[P];
};

Well, I found that there was an easier way used the builtin types:

type ProtoExntends<T, U> = U & Omit<T, keyof U>;

And for the example usage:

interface Parent {
  aaa: number;
  bbb: number;
  // .
  input(stream: {}): void;
  allowedSounds: 'BARK' | 'MOO';
}
interface ChildExtends {
  aaa: string;
  ccc: string;
  // .
  input(stream: {}, coordinates: {x: number; y: number}): void;
  allowedSounds: 'BARK' | 'MOO' | 'CAW';
}
type Child = ProtoExntends<Parent, ChildExtends>;

It looks everything works well as the screenshots shows: image image image image image

10reactions
shobhitgcommented, Feb 1, 2018

This issue is also applicable for enums that are overridden.

interface BaseType
{
    allowedSounds: 'BARK' | 'MOO';
}
interface DerivedType extends BaseType
{
    allowedSounds: 'BARK' | 'MOO' | 'CAW';
}

This currently results in the following error:

Interface 'DerivedType' incorrectly extends interface 'BaseType'.
  Types of property 'allowedSounds' are incompatible.
    Type '"BARK" | "MOO" | "CAW"' is not assignable to type '"BARK" | "MOO"'.
      Type '"CAW"' is not assignable to type '"BARK" | "MOO"'.

But from a language point of view, it is a totally legit expectation to be able to override enums in DerivedTypes.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Interface A incorrectly extends interface B - Stack Overflow
Interface 'Props' incorrectly extends interface 'HTMLAttributes'. Types of property 'property' are incompatible. Type 'SerializedObject' is not ...
Read more >
Firepower Management Center Device Configuration Guide, 7.1
This chapter includes regular firewall FTD interface configuration including EtherChannels, VLAN subinterfaces, IP addressing, and more.
Read more >
Junos Telemetry Interface User Guide - Juniper Networks
One primary function of the Junos Telemetry Interface is performance monitoring. Streaming data to a performance management system enables ...
Read more >
Configure a Layer 2 Interface, Subinterface, and VLAN
Configure a Layer 2 interface and subinterface and assign a VLAN ID. Select. Network. Interfaces. Ethernet. and select ...
Read more >
Classes and mixins
gramming with single inheritance classes, but mixins more directly encourage programming to interfaces. The paper develops these ideas within the context of.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found