TypeScript: Missing property declaration in abstract class implementing interfaces

Just ran into this, was very surprised by the behaviour. Why an already abstract class needs to redefine interface methods as abstract is beyond me.

@mhegazy I used to think that abstract classes are just like interfaces but with some members implemented. I know that TypeScript very often works non-intuitively different from other languages, but that is the difference in this specific case comparing to languages that don’t have such problems with abstract classes?

If you describe the problem with a concrete example I will appreciate this very much.

Although, the convenience of not writing the declaration would be nice, the possible confusion/complexity arising from this change would not warrant it. by examine the declaration, it is not clear which members appear on the type, is it all properties, methods, or properties with call signatures; would they be considered abstract? optional?

For a motivating example:

interface Clock {
    enable(): void; // Specific to each implementer
    disable(): void; // Specific to each implementer
    setEnabled(value: boolean): void; // Common across implementers. Calls one of the above.
}

abstract class BaseClock implements Clock { // Complains that BaseClock doesn't implement all members of Clock. Of course it doesn't! It's abstract!
    // Common implementation for all derived classes
    setEnabled(value: boolean): void {
        if (value) {
            this.enable(); // If it didn't implement Clock, it couldn't call this anyway.
        }
        else {
            this.disable();
        }
    }
}

Of course we can keep declaring setEnabled in each derived class as an instance property setEnabled: (value: boolean) => void; and then add it to each prototype with a mixin, but it would’ve been nice for ABCs to do this automatically. It limits the usefulness of ABCs severely if they can only reference their own members.

---

And you can’t work around this by adding stubs enable: () => void; disable: () => void; to the ABC to satisfy the interface because the derived class then can’t implement them as methods: error TS2425: Class 'BaseClock' defines instance member property 'enable', but extended class 'DerivedClock1' defines it as instance member function.

---

A workaround that continues to use ABCs is to implement everything in the ABC and duplicate everything that needs to be implemented in derived classes as abstract protected methods, which is ugly as hell.

interface Clock {
    enable(): void;
    disable(): void;
    setEnabled(value: boolean): void;
}

abstract class BaseClock implements Clock {
    enable(): void {
        this._enable();
    }

    disable(): void {
        this._disable();
    }

    setEnabled(value: boolean): void {
        if (value) {
            this._enable();
        }
        else {
            this._disable();
        }
    }

    protected abstract _enable(): void;
    protected abstract _disable(): void;
}

class DerivedClock1 extends BaseClock {
    protected _enable() {
        console.log("enable");
    }

    protected _disable() {
        console.log("enable");
    }
}

I agree that this behavior is a bit unexpected. As an alternative, I’ve been getting around this using interface merging.

The code below results in a compile time error:

interface A {
    x: any;
}

// ERROR: Class 'B' incorrectly implements interface 'A'. 
//        Property 'x' is missing in type 'B'.
export abstract class B implements A {
    y: any;
}

I’ve been avoiding the compile time error by using something like this instead:

interface A {
  x: any;
}

// Merge interface B with the abstract class declaration below.
export interface B extends A {}

// Note that the 'implements A' here is optional... you can remove it if you like.
export abstract class B implements A {
  y: any;
}

I agree that this behavior is very unexpected.

Just small question, because this is for me probably most annoying feature of TypeScript - how much of you are using TS with PHP, thus you have a “compact” abstracts with the “heavy” ones on TS side?

I have one general usage patter:

interface IFoo {
    enable(enable: boolean): IFoo;
    proprietary(): IFoo;
}

abstract class AbstractFoo implements IFoo {
    // ...code here
}

class FooBar extends AbstractFoo { // missing implements as it's enough to refer to abstract impl.
    // ... cool stuff here
}

I would be really happy too to not be forced to reuse all methods from interfaces in abstracts.

quite surprising behavior for me as well - don’t think that it would introduce any risks, at least for scenarios that @mhegazy has mentioned. Actually, it could be much more easier for the code reader to dissect all the different methods and understand which particular behavior aspects where introduced either by interface or abstract class. And from the maintenance perspective, as @Arnavion has already mentioned here, it would be an additional work required to be done each time you’ll change the interface - it would require additional changes in the abstract class which, in fact, should just introduce its behavior aspects which it is responsible for and, thus, it should not be touched each time the interface has changed.