Polymorphism, and the TypeScript setup that breaks on a fresh install

Last session finished encapsulation and inheritance. This one closes the OOP run with the inheritance shapes and polymorphism, then starts TypeScript. Today's exercises run to lab 196.

This is the last JavaScript-only class. From here every file is .ts.

The question in an interview is almost always phrased the same way: what are the types of inheritance, and which ones does JavaScript support. There are five worth naming.

The rule to carry into an interview is short. Single, multi-level and hierarchical are supported, all with the same extends keyword. Multiple is not, and hybrid is not, because hybrid always contains a multiple.

One father can have as many children as you like, so hierarchical is fine. One child cannot have two fathers, so multiple is not. That was the analogy used in the room, and it survives the interview.

Worth knowing that the failure is not subtle. Writing two parents is rejected before anything runs:

class F1 {}
class F2 {}
class Son extends F1, F2 {}

class F1{}; class F2{}; class Son extends F1, F2 {}
                                            ^
SyntaxError: Unexpected token ','

Multiple inheritance does have a way in, and it has a name: mixins. A mixin is a function that takes a class and returns a new class extending it. Because it is a function, you can nest calls, and a class can end up with behaviour from several sources.

const LoginMixin = (Base) => class extends Base { login() { return 'login'; } };
const ShotMixin  = (Base) => class extends Base { shot()  { return 'shot';  } };

class TestCase { run() { return 'run'; } }

class SmartTest extends LoginMixin(ShotMixin(TestCase)) {}

const s = new SmartTest();
console.log(s.run(), s.login(), s.shot());
console.log(s instanceof TestCase);

run login shot
true

It works, and instanceof TestCase still holds, so the chain is real inheritance rather than object copying.

Polymorphism is one object behaving differently depending on what it actually is. The analogy from the room: you speak to your mother, your friends and your colleagues in three different ways, and you are still one person.

In a language like Java that splits two ways:

Only overriding exists in JavaScript. A child class declares a method with the same name as its parent, and which one runs is decided by the object you created.

class BaseTest {
  setup() { console.log('base setup'); }
}

class ApiTest extends BaseTest {
  setup() { console.log('api setup'); }
}

new ApiTest().setup();
new BaseTest().setup();

api setup
base setup

There is no @Override annotation as there is in Java. You just declare the method again.

This is the part worth slowing down on, because "not supported" makes it sound like JavaScript will stop you. It will not.

class BaseTest {
  setup(a)    { return `one-arg: ${a}`; }
  setup(a, b) { return `two-arg: ${a},${b}`; }
}

const t = new BaseTest();
console.log(t.setup('x'));
console.log(t.setup('x', 'y'));

two-arg: x,undefined
two-arg: x,y

The second declaration replaced the first. There is one setup on the prototype, not two, and calling it with one argument runs the two-argument version with b as undefined. No warning, no error.

An exercise from the session, and the kind that gets asked because it looks harder than it is.

class A { who() { return 'A'; } }
class B extends A { who() { return 'B > ' + super.who(); } }
class C extends B { who() { return 'C > ' + super.who(); } }

console.log(new C().who());

C > B > A

Read it as a chain rather than a puzzle. new C() runs C's who, which prints C and then hands off to B with super.who(), which prints B and hands off to A. The answer is C, then B, then A.

The follow-up is the useful half. Drop the override and the parent runs instead:

class D extends B {}
console.log(new D().who());

B > A

That is the fallback rule from the dispatch diagram, doing exactly what it says.

The switch happens here, and the framing from the room is the one to keep: TypeScript is not a different language. It is JavaScript with rules layered on. Same person, wearing a jacket.

Every .ts file ends up as JavaScript. That is not an implementation detail you can ignore, it is the whole design. If a rule cannot be expressed in JavaScript, TypeScript cannot enforce it at runtime.

The one concrete thing a type annotation buys you: let timeout = 5 leaves the reader guessing whether 5 is a number or a string. let timeout: number = 5 does not.

Three commands were shown, and this is where a fresh install today diverges from the machine used in class.

npm install -D typescript
npx tsc --version
npx tsc --init

tsc --init writes a tsconfig.json. The three lines worth looking at:

"module": "nodenext",
"target": "esnext",
"strict": true

Ignore the rest of that file for now. It matters when Playwright arrives, not before.

Then there are two different jobs, and they are easy to confuse:

Compiling by hand shows what TypeScript actually produces. The emitted file opens with "use strict", which is the "follow the rules" switch turned on in plain JavaScript.

TypeError: Cannot read properties of undefined (reading 'fileExists')
    at readConfig (.../ts-node/dist/configuration.js:91:33)

Three ways out, all checked on Node v22.22.3:

The Node flag is the tempting one and it is the one to be careful with. It removes type annotations and runs what is left, so it cannot handle TypeScript that is more than annotations:

enum Severity { Low, High }
class Bug {
  constructor(private title: string, public sev: Severity) {}
}

ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX

enum and constructor parameter properties are exactly what the next class covers, along with private, public, protected and abstract classes. tsx runs that file without complaint. Install tsx now and you will not have to change tooling mid-topic.

An annotation goes in three places: on a variable, on each parameter, and on the return.

let testName: string = "login test";

function add(a: number, b: number): number {
  return a + b;
}

function sayHello(message: string): void {
  console.log(`Hi ${message}`);
}

const multiply = (a: number, b: number): number => a * b;

Arrow functions annotate exactly the same way. Nothing special about them.

The types covered:

void against never is the pair that gets asked. void means the function finishes and hands nothing back. never means the function does not finish: it throws every time, or it loops forever.

function log(msg: string): void {
  console.log(msg);
}

function fail(msg: string): never {
  throw new Error(msg);
}

Empty return is void. No return, ever, is never. never is rare in test code and it is worth recognising rather than reaching for.

any against unknown is the pair that matters more day to day, because one of them turns the type checker off.

let a: any = "hello";
a.definitelyNotAMethod();

let u: unknown = "hello";
u.definitelyNotAMethod();

any compiles clean and then explodes at runtime. unknown is rejected at compile time, which is the entire point of it. To use an unknown you have to prove what it is first:

let u: unknown = "hello";

if (typeof u === "string") {
  console.log(u.toUpperCase());
}

Inside the if, TypeScript knows it is a string and lets you call string methods. That is called narrowing.

Both are escape hatches. unknown is the safe one because it forces the check. Reach for a real type first.

• From here every file is .ts. Not .js. The folder for TypeScript work is 25_TypeScript.
• Install tsx before you start the homework. npm i -D tsx, then npx tsx yourfile.ts. It saves the ts-node failure above and it will still be the right tool next class.
• Next class continues TypeScript: interfaces, enums, generics, private, public, protected, readonly, abstract classes, type assertions, decorators and tuple types. Abstraction is covered there rather than in JavaScript.
• This week's target is to finish TypeScript and go straight into Playwright.
• Weekly test: released Sundays at 9 AM and open for 12 hours, so you can take it whenever suits you inside that window. JavaScript parts 3 and 4 are next.
• The OOPs interview questions in the Playwright section of the portal are worth marking off as you learn each one.