Proposal for Abstract Classes and Methods

[aozgaa]

Proposal for Keyword abstract

This is a proposal for a new keyword, abstract, to allow for incomplete/partially implemented classes.

Introduction

This proposal expands upon #6, #2946, #2947.

Consider the following situation. A user would like to create a base class that shouldn't be instantiated as a template for derived classes. S/he might write something like

class Animal {
 public age : number;
 public yearsLeft() { return 20 - this.age; }
 public makeSound() : string { return "???"; }
}

class Cow extends Animal {
 makeSound() { return "Moo"; }
}

class Cat extends Animal {
 makeSound() { return "Meow"; }
}

Today, the writer is forced to make a choice: either (i) Animal can be declared an interface, but then yearsLeft cannot have an implementation, or (ii) write the program as above, but then Animal can be instantiated and makeSound has a bogus implementation! Neither of these options is particularly attractive.

We propose abstract as a class declaration modifier to allow the programmer control over whether a class can be instantiated, and as a member function modifier to control whether said member function offers an implementation (and whether the enclosing class is abstract).

Details

The modifier abstract can prepend a class declaration or a member function declaration. Constructors cannot be declared abstract.

• Objects whose type is typeof C where C is an abstract-declared class (hereafter abstract class) cannot be instantiated via calls to new.
• A member function declared abstract does not have an implementation.
• Abstract methods cannot be called within a class member function body via super.foo() where foo is an abstract method belonging to the parent class.
• Abstract methods may be called within a class member function body via this.foo() where foo is an abstract method belonging to that class.
• If a class has any abstract methods, then the class itself must be declared abstract.
• Abstract methods are inherited.
• Abstract methods can be overridden in the derived class, either by an abstract method (effectively a re-declaration) or a function declaration that offers an implementation.
• A method cannot be simultaneously abstract and static.
• A method cannot be simultaneously abstract and private.
• If an abstract member declaration contains an explicit accessibility modifier, then the modifier must precede the abstract keyword.
• Overloads on a member function must be either all abstract or all not abstract.
• Overloads of abstract member functions must be declared adjacent to eachother.
• Objects whose type is the type of an abstract class can only be assigned to other objects whose type is the type of an abstract class. For example,

The following code snippet summarizes valid and invalid usages of the abstract keyword

class A {
 // ...
}

abstract class B {
 foo(): number { return bar(); }
 abstract bar() : number;
}

new B; // error

import myB = B;
new myB; // error

var BB: typeof B = B;
var AA: typeof A = BB; // error, AA is not of abstract type.
new AA;

function constructB(Factory : typeof B) {
 new Factory; // error -- Factory is of type typeof C
}

var BB = B;
new BB; // error -- BB is of type typeof C

var x : any = C;
new x; // okay -- undefined behavior at runtime


class C extends B { } // error -- not declared abstract

abstract class D extends B { } // okay

class E extends B { // okay -- implements abstract method
 bar() { return 1; }

abstract class F extends B {
 abstract foo() : number;
 bar() { return 2; }
}

abstract class F {
 abstract qux(x : number) : string;
 abstract qux() : number;
 y : number;
 abstract quz(x : number, y : string) : boolean; // error -- declarations must be adjacent

 abstract nom() boolean;
 nom(x : number) boolean: // error -- use of modifier abstract must match on all overloads.
}

class G { // error -- not declared abstract
 abstract baz() : number;
}

Pros

• Allows the programmer to write partial implementations of a class.
• Provides a mechanism for the type system to warn about classes that shouldn't be instantiated.
• abstract annotations clarify the role of base classes in various patterns.

Cons

• Increases the complexity of the language.

To Be Discussed

• Should abstract be allowed within class expressions?

Proposed Changes to Grammar

A.6 Classes

ClassDeclaration:
abstract_opt class Identifier TypeParameters_opt ClassHeritage { ClassBody }

MemberFunctionDeclaration:
MemberFunctionOverloads_opt MemberFunctionImplementation
AbstractMemberFunctionOverloads

AbstractMemberFunctionOverloads:
AbstractMemberFunctionOverload
AbstractMemberFunctionOverloads AbstractMemberFunctionOverload

AbstractMemberFunctionOverload:
AccessibilityModifier_opt abstract PropertyName CallSignature ;

A.10 Ambients

AmbientClassDeclaration:
abstract_opt class Identifier TypeParameters_opt ClassHeritage { AmbientClassBody }

AbstractOrStatic:
abstract
static

AmbientPropertyMemberDeclaration:
AccessibilityModifier_opt AbstractOrStatic_opt PropertyName CallSignature ;

EDIT: updated to clarify the assignability of objects of "abstract type".

[CKGrafico]

Thanks for that!

[mhegazy]

Moreover, the assignability of abstract types is restricted to instances that are abstract

I do not understand what you mean by this.

[jbondc]

• Increases the complexity of the language.

Pretty much how I feel about it. I'd rather see a more lean functional-like TypeScript then adding astronaut like OO patterns like abstract or decorators.

This overlaps tons with mixins or traits too (combining things from other things). The benefit of traits or mixins is you can design 'abstract patterns' that work with modules too. This proposal is limited to a 'class' which lets face it is really a function under the hood.

[aozgaa]

Mohamed Hegazy (@mhegazy) This definitely needs re-wording.

We want to prevent the constructor of an abstract class from being invoked. So we wanted to restrict the assignability of the constructor function. Consider the following example:

class A {}
abstract class B extends A {}

var BB: typeof B = B;
var AA: typeof A = BB;
new AA;

We don't want the second assignment to be legal. So we restrict the assignabilty of objects whose type is the type of an abstract class to other objects whose type is the type of an abstract class.

I haven't yet implemented this as part of the attached PR.

I've updated the spec to clarify this.

[zpdDG4gta8XKpMCd]

Jon (@jbondc) so true, inheritance (for the sake of code "reuse" or whatever else) is a hands down rotten idea, composition does it all with a little bit more effort, screw this s*t

[Gaelan]

👍

[jbondc]

💩 I'd love to hear how this aligns with the design goals:

5. Produce a language that is composable and easy to reason about.
6. Align with current and future ECMAScript proposals.

Non-goals
1. Exactly mimic the design of existing languages. Instead, use the behavior of JavaScript 
and the intentions of program authors as a guide for what makes the most sense in the language.

[kitsonk]

I have long argued of the merits of embracing the protypical nature of ECMAScript instead of projecting a traditional OO paradigm. On the other hand, that hasn't stopped the wider community rejecting that and ECMAScript has taken a large bend towards traditional OO with ES6, though there seems much debate on this, as several of our ECMAScript luminaries seems to be conflicted on every aspect of this.

Jon (@jbondc) I think it is a fair challenge to question this proposal in line with design goals 5 and 6. It is very likely that some sort of abstract/traits/composition type features will end up in ES, though there seems to be no common consensus. Both abstract and traits were proposed during the class discussions in ES6/2015, but all got dropped because no one could agree. TypeScript already has interfaces which provide a sufficient level of abstraction ahead of any implementation of something along this line of ES.

The traits discussion (#311) was closed by Ryan Cavanaugh (@RyanCavanaugh) because of this conflicting with goal 6. I quote:

There's a lot of overlap here with mix-ins; it would be bad (or at least treacherous) to do both. With mix-ins being a potential part of ES7/ES8+, we want to take the runtime side of this very conservatively and get TC39 to agree on a proposal in this area first.

I honestly don't see what the difference is here.

Jon (@jbondc) so true, inheritance (for the sake of code "reuse" or whatever else) is a hands down rotten idea, composition does it all with a little bit more effort, screw this s*t

While I am personally a fan of compostability, a strong emotive response without well thought arguments is unlikely to further your thoughts, especially when it appears you want to throw your arms up in the air and walk away. I don't think that is your intent, but that is the way it comes across.

[zpdDG4gta8XKpMCd]

Here is the statement: inheritance is a dangerous tool that causes more problems than solves

• it takes knowledge, practice and discipline to use it right (which junior/mid developers generally lack)
• it takes experience to grasp the understanding where it may NOT be used
• yet, given all of above, even experienced developers with well designed systems fall short when requirements change and it comes to redesign and it turns out that existing inheritance hierarchies are too rigid to change

All this contributes to frustration, missed deadlines, and myths that coding is hard. In my experience nothing is hard if designed properly. Well, inheritance encourages bad design by allowing developers to violate:

• (open closed principle)[https://en.wikipedia.org/wiki/Open/closed_principle]
• (Liskov substitution principle)[https://en.wikipedia.org/wiki/Liskov_substitution_principle]

Besides that

• having to choose one single super-class among a few possible others inevitably favoring one predecessor over all equally important others, resulting to skewed hierarchies
• in a sub-class, having to comply to the interface of the super-class even though it goes against the needs
• leaving a class unclosed and allowing uncontrolled sub-classing that wasn't intended

Besides that, there is quite a number of successful examples of languages without inheritance at all:

• (COM)[https://www.microsoft.com/com/default.mspx] where code reuse is achieved with interface inheritance and composition only
• functional lanaguges where code reuse is achieved by various means (parametrizing with functions, typeclasses, class modules) without having to alter the existing code

[DanielRosenwasser]

Alright, while we'd love to have a constructive conversation on the merits of different approaches in software design, I believe that classes are a useful abstraction and the abstract modifier would bring utility. For those who prefer using this paradigm, it would surely be helpful.

Unless there are specific "gotchas" introduced in our language from abstract that are not found in other languages, I disagree that users would find this extremely complex. If one understands classes and one understands interfaces, then abstract classes do not require a massive cognitive leap.