Class declarations should implicitly implement interfaces

[mwisnicki]

http://typescript.codeplex.com/workitem/1125

Following should be allowed:

interface IFoo {
    foo();
}

declare class Foo implements IFoo {}

If abstract classes are added in the future, they would inherit all interface methods as abstract (like in Java).

[Bartvds]

+1 It would remove a lot of code duplication on declaration files.

[basarat]

👍

The kind of thing you don't know you need till you see it suggested. In the absence of this many times DT PR's break tests because they need to go to all the places and add these members. (which is fine-ish)

More importantly for something like spacepen (used by atom.io) that implements JQuery we (the wise @vvakame) just decided not put them in and leave it in a comment (otherwise we would need to fix up the definition everytime someone added a new JQuery plugin definition).

https://github.com/borisyankov/DefinitelyTyped/blob/e9b0f608b1ca18344b2a916048594c8f30b0df10/space-pen/space-pen.d.ts#L52

declare class View /* implements JQuery */ {

[basarat]

If its decided to add this, I also have breaking change proposal. I think the following should be prevented and give an error as shown:

interface IFoo {
    foo();
}

declare class Foo implements IFoo {
    foo(); // Error: Already has member foo
}

That will make implementing this feature easier and consistent.

[mwisnicki]

Why ? It's allowed for classes:

declare class Foo {
    foo();
}

declare class Foo2 extends Foo {
    foo();
}

It's quite useful - you can put additional documentation on Foo2.foo this way.

[RyanCavanaugh]

The problem is that if you assume classes have their declared interface's members, it becomes very unclear/confusing what it means if you explicitly write those members:

/* Input code */
interface SomeInterface1 {
    getThing(x: string): Element;
}

interface SomeInterface2 {
    getThing(x: number): HTMLElement;   
}

declare class SomeClass implements SomeInterface1, SomeInterface2 {
    getThing(x: any): HTMLCanvasElement;
}

/* What does the definition of SomeClass mean? */

// First answer: Same thing it meant in TypeScript 1.0, because
// this doesn't justify a breaking change
module Alpha {
    declare class SomeClass implements SomeInterface1, SomeInterface2 {
        getThing(x: any): HTMLCanvasElement;
    }
}

// Second answer: The class implementation is just another
// signature, so append it to the list of signatures we got from
// the interfaces
module Beta {
    declare class SomeClass implements SomeInterface1, SomeInterface2 {
        getThing(x: string): Element;
        getThing(x: number): HTMLElement;   
        getThing(x: any): HTMLCanvasElement;
    }
}

// Third answer: The class implementation should come first because
// it's the most important one (even though this creates unreachable signatures)
module Gamma {
    declare class SomeClass implements SomeInterface1, SomeInterface2 {
        getThing(x: any): HTMLCanvasElement;
        getThing(x: number): HTMLElement;   
        getThing(x: string): Element;
    }
}

// Fourth answer: This is disallowed?
module Delta {
    /* Breaking change, SomeClass is an error */
}

Then, under the proposal:

/* Input code, changed slightly */
interface SomeInterface1 {
    getThing(x: string): Element;
}

interface SomeInterface2 {
    getThing(x: number): HTMLElement;   
}

declare class SomeClass implements SomeInterface1, SomeInterface2 { }

/* What does the definition of SomeClass mean? */

// First answer: this is an error because SomeInterface1 and SomeInterface2
// have conflicting members
module Alpha {
    /* error */
}

// Second answer: The class is assumed to have both overloads
module Beta {
    declare class SomeClass implements SomeInterface1, SomeInterface2 {
        getThing(x: string): Element;
        getThing(x: number): HTMLElement;   
    }
}

// Third answer: Something else?
module Gamma {
    declare class SomeClass implements SomeInterface1, SomeInterface2 {
        /* ? */
    }
}