What exactly do you miss? JS has built-in reflection, eg `typeof instance`, `instance.constructor.name`. Even multiple dispatch can be hacked together if you really need it, eg there is a library @arrows/multimethod.
class Dog { woof(){} }
class Cat { meow(){} }
function f(a: Dog|Cat) {
if (a instanceof Dog) {
a.woof()
} else {
a.meow()
}
}
let dogish = {woof: ()=>{}}
f(dogish)
type userId = string;
type subscriptionId = string;
const uid: userId = 'userA';
const sid: subscriptionId = uid; // compiler is OK with thisHere's how type aliases are usually documented: "Type aliases do not introduce new types. They are equivalent to the corresponding underlying types."
The person above did have a better example of the downside: You usually want something to nominally comply with a specific interface, not structurally. i.e. Just because something happens to have an `encrypt(u8[]): u8[]` method doesn't mean you want to accept it as an argument. (Go interfaces have a similar issue.)
Do this:
interface Dog { typeName: "Dog"; woof():void }
interface Cat { typeName: "Cat"; meow():void }
function isDog(a:Dog|Cat) : a is Dog {
return a.typeName == "Dog"; // Some casting may be required here
}
function f(a: Dog|Cat) {
if (isDog(a)) a.woof();
else a.meow();
}
let dogish : Dog = {typeName:"Dog", woof: ()=>{ console.out("Woof this is Dog")}};
f(dogish);
(And if you only need compile-time checks, you can make typeName nullable; {typeName?:"Dog"} != {typeName?:"Cat"})
type SpecificJsonBlob = {x: number};
function serialize(s: SpecificJsonBlob) { return JSON.stringify(s); }
function addOneToX(s: SpecificJsonBlob) { s.x += 1 }
[...]
let o = { get x() { return 1 } }
serialize(o)
addOneToX(o)
There's obviously other cases of ergonomic benefit to structural typing (including that idiomatic JS duck-typing patterns work as you'd hope), but I think its not unreasonable for someone to feel that it's their biggest problem with typescript (as grandparent OP did).