undefined | Better HN

0 pointsLudwigNagasena2y ago0 comments

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.

0 comments

esrauch2y ago

Those don't change that the type system is structural; the type system is actually not fully safe if you use the things you mention, eg:

  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)

This compiles because dogish is structurally a dog, the type system allows instanceof to narrow the type but "dogish instanceof Dog" is actually false, so at runtime this will crash after trying to call meow on dogish.

TOGoS2y ago

Yeah don't do that. :)

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);

The neat thing about TypeScript's type system is that it's structural but you can pretty easily implement nominal types on top of it.

(And if you only need compile-time checks, you can make typeName nullable; {typeName?:"Dog"} != {typeName?:"Cat"})

esrauch2y ago

Sure, but opt-in nominal types that you describe is still something of a foot-gun that you have to be wary of since its easy to accidentally pass something that conforms to the structural type but violates whatever expectation. Like here's an example:

  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)

This compiles because the getter makes it structurally conform to the type, but the 'serialize' will surprisingly return just '{}' since JSON.stringify doesn't care about getters, and addOneToX(o) is actually just a runtime crash since it doesn't implement set x. These are runtime issues that would be precluded by the type system in a normal structural typed language.

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).

1 more reply

black_puppydog2y ago

This is pretty much what I ended up with (with a string const generic type param actually) but now I have this extra implementation detail that I need to add/remove at every service boundary. It just makes every serialization/deserialization more complicated and generally adds cruft.

LudwigNagasenaOP2y ago

The fact that it compiles is due to the TypeScript’s goal of being pragmatic rather than sound. If an instance isn’t derived from the class Dog, it doesn’t mean that it doesn’t conform to the type/interface Dog, yet TypeScript assumes it means that for the instance of check. It has more to do with TypeScript being a bolt-on over JavaScript that has to take into account existing codebases rather than with TypeScript being structurally typed.

black_puppydog2y ago

My classic example case is actually even simpler IMHO:

    type userId = string;
    type subscriptionId = string;
    
    const uid: userId = 'userA';
    const sid: subscriptionId = uid; // compiler is OK with this

hombre_fatal2y ago

Isn't that just how type aliases work rather than anything to do with structural typing? That example also compiles in Haskell and Go and Kotlin.

Here'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.)

wtetzner2y ago

Those are just type aliases. They're just different names for `string`.

j / k navigate · click thread line to collapse

0 comments

esrauch2y ago

Those don't change that the type system is structural; the type system is actually not fully safe if you use the things you mention, eg:

  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)

TOGoS2y ago

Yeah don't do that. :)

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);

The neat thing about TypeScript's type system is that it's structural but you can pretty easily implement nominal types on top of it.

(And if you only need compile-time checks, you can make typeName nullable; {typeName?:"Dog"} != {typeName?:"Cat"})

esrauch2y ago

  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)

1 more reply

black_puppydog2y ago

LudwigNagasenaOP2y ago

black_puppydog2y ago

My classic example case is actually even simpler IMHO:

    type userId = string;
    type subscriptionId = string;
    
    const uid: userId = 'userA';
    const sid: subscriptionId = uid; // compiler is OK with this

hombre_fatal2y ago

Isn't that just how type aliases work rather than anything to do with structural typing? That example also compiles in Haskell and Go and Kotlin.

Here's how type aliases are usually documented: "Type aliases do not introduce new types. They are equivalent to the corresponding underlying types."

wtetzner2y ago

Those are just type aliases. They're just different names for `string`.

j / k navigate · click thread line to collapse