Suggestion: abstract classes

[RyanCavanaugh]

Support an abstract keyword for classes and their methods

Examples:

abstract class Base {
    abstract getThing(): string;
    getOtherThing() { return 'hello'; }
}
var x = new Base(); // Error, 'Base' is abstract

// Error, must either be 'abstract' or implement concrete 'getThing'
class Derived1 extends Base { }

class Derived2 extends Base {
    getThing() { return 'hello'; }
    foo() { super.getThing(); } // Error: cannot invoke abstract members through 'super'
}
var x = new Derived2(); // OK
var y: Base = new Derived2(); // Also OK
y.getThing(); // OK
y.getOtherThing(); // OK

abstract class Empty { } // OK

[am11]

👍

The example would be more awesome if you incorporate virtual as well. 😄

abstract class Base {
    abstract getThing(): string;
    getOtherThing() { return 'hello'; }
    virtual getVirtualThing() { return 'hello virtual'; }
}
...

[DanielRosenwasser]

@am11 given that methods in JS get called by traversing the prototype chain, all methods are already "virtual" in the traditional sense that C++, C#, Java, and similar languages define it.

For instance:

class E { 
    f () { alert("E"); }
}

class F extends E {
    f () { alert("F"); }
}

var x: E = new F();
x.f();

will alert "F".

Did you have something else in mind?

[am11]

@DanielRosenwasser, that is so true. Thanks!

Actually, I was thinking about the conventional OO keywords virtual and overrirde, so its easy to clearly differentiate between various inheritance behaviors. The TS compiler might just throw warning if those keywords are missing in applicable scenarios and fallback to standard JS convention.

I believe this way we can bring C#'s new modifier as well:

abstract class A {
    public void foo() { }
    protected virtual void bar() { }
}

class A1 : A {
    protected override void bar() { }
}

there may exist A2, such that:

class A2 : A {
    public new void foo() { }
}

to explicitly hide super's implementation (without new keyword there, CS compiler gives warning).

[RyanCavanaugh]

new is infeasible given JavaScript's runtime semantics; given that we've already shipped the language this way, virtual would be the default in the absence of any other modifier. Let's take discussion of those modifiers to a different suggestion if needed.

Seems like the example above has enough information to discuss. Some open questions:

• Can I have an abstract class with zero abstract methods?
• Is the abstract modifier implicit in a class that doesn't implement all abstract methods?

[am11]

Can I have an abstract class with zero abstract methods?

Since abstract class -- in principle -- serves a purpose of grouping commonalities together such that its objects alone don't make sense; I think we should rule no_abstract_method as a legit case and let the TypeScript linter take care of recommending best practices, code-styling et el.

Is the abstract modifier implicit in a class that doesn't implement all abstract methods?

Given an abstract class would be able to inherit another abstract class, implicit inference like this would be confusing? I guess (at least C#/Java) developers would expect compiler to throw error and editor to help them correct it, if the first non-abstract / concrete implementer is missing any expected override. Well as a Ruby guy, I'd probably appreciate this kind of crypto-magic :`)

[RamIdeas]

Even before abstract is implemented, I'm still hoping you'd allow intellisense kick in (in Visual Studio) when overriding base class functions:

class BaseClass {
  myFunction() { /* TO BE OVERRIDDEN */ }
}
class MyClass extends BaseClass {
  myF // intellisense should have kicked in -- but it doesn't
}

My only option is to open BaseClass.ts to check I'm spelling it correctly.

[RamIdeas]

I'd still prefer to see more descriptive keywords, as I mentioned on https://typescript.codeplex.com/discussions/449920

C#	VB (on classes)	VB (on methods)
abstract	MustInherit	MustOverride
virtual	Overridable	Overridable
sealed	NotInheritable	NotOverridable

From these more descriptive keywords, it can be seen immediately that the overridable keyword is unnecessary as methods in JavaScript are overridable by default as opposed to in C# and is less likely to lead to confusion demonstrated by @am11. I believe the same gain in clarity is achieved with the other keywords listed.

[RyanCavanaugh]

We're trying to clear out our design backlog and I think this should come up soon once ES6 features are wrapped up. We discussed abstract in a design meeting a few months ago and there didn't seem to be any big open questions.

[metaweta]

The standard design pattern in JS is to throw an exception in the abstract class:

function Base() { throw new Error("Not implemented."); }
Base.prototype.f = function () { throw new Error("Not implemented."); };
Base.prototype.g = function () { /* default impl */ };

function Derived() {}
Derived.prototype.f = function () { /* impl */ };
Derived.prototype.g = function () { /* override impl */ };

The benefit TypeScript could provide is reducing boilerplate and a compile-time error.