3 ms·

I had the impression, my code gets less polymorphic when I use TypeScript.

by k__ 4y ago

hajile 4y ago
If only. This is polymorphic because union types are polymorphic. let stringProcessor = (foo: string | number): string => { //do stuff with foo return "string" + foo } It's super easy to make non-optimized arrays and objects this way. type MyFoo = string | number //somewhere in the codebase //you will get zero hints that this is a polymorphic function let formatFoos = (foos: MyFoo[]) => foos.map((foo) => `${foo} deoptimized`)) Any use of optional object properties also immediately leads to polymorphism too. I doubt you can find ANY significant TS codebase where this isn't used pervasively. interface Foo { foo: MyFoo //polymorphic bar: string baz?: number //this is polymorphic too } let doStuff = (obj: Foo): string { //do stuff with obj return "string" } doStuff({bar: "abc"}) doStuff({bar: "abc", baz: 123}) //we're now polymorphic Even if we remove the `?`, it can still be polymorphic because the TS compiler doesn't reorder object properties when compiling. interface Foo { bar: string //all basic types, so we're good? baz: number //no more optional, so we're fine right? } let doStuff = (obj: Foo): string { //do stuff with obj return "string" } doStuff({baz: 123, bar: "abc"}) doStuff({bar: "abc", baz: 123}) //we changed order, so now we're now polymorphic
- brundolf 4y ago
  I'm very surprised the property ordering would matter. Seems like the JS engine itself could easily fix that, no? Silently re-order the properties to fit its own optimization Do you have a source for the above info? (both because I'm a little skeptical of some parts of it, but also because I'd love to learn more about this topic and I've had trouble finding concrete info in the past)
  - hajile 4y ago
    JS specifies that the order keys are added makes a difference. For this reason, entering them in two different ways is a fundamentally different, non-interchangeable object type.
    - brundolf 4y ago
      You could preserve that information and still have the same native struct, since it only becomes relevant when iterating the keys

I had the impression, my code gets less polymorphic when I use TypeScript.

by k__ 4y ago

I had the impression, my code gets less polymorphic when I use TypeScript.

If only. This is polymorphic because union types are polymorphic. let stringProcessor = (foo: string | number): string => { //do stuff with foo return "string" + foo } It's super easy to make non-optimized arrays and objects this way. type MyFoo = string | number //somewhere in the codebase //you will get zero hints that this is a polymorphic function let formatFoos = (foos: MyFoo[]) => foos.map((foo) => `${foo} deoptimized`)) Any use of optional object properties also immediately leads to polymorphism too. I doubt you can find ANY significant TS codebase where this isn't used pervasively. interface Foo { foo: MyFoo //polymorphic bar: string baz?: number //this is polymorphic too } let doStuff = (obj: Foo): string { //do stuff with obj return "string" } doStuff({bar: "abc"}) doStuff({bar: "abc", baz: 123}) //we're now polymorphic Even if we remove the `?`, it can still be polymorphic because the TS compiler doesn't reorder object properties when compiling. interface Foo { bar: string //all basic types, so we're good? baz: number //no more optional, so we're fine right? } let doStuff = (obj: Foo): string { //do stuff with obj return "string" } doStuff({baz: 123, bar: "abc"}) doStuff({bar: "abc", baz: 123}) //we changed order, so now we're now polymorphic

brundolf 4y ago
I'm very surprised the property ordering would matter. Seems like the JS engine itself could easily fix that, no? Silently re-order the properties to fit its own optimization Do you have a source for the above info? (both because I'm a little skeptical of some parts of it, but also because I'd love to learn more about this topic and I've had trouble finding concrete info in the past)
- hajile 4y ago
  JS specifies that the order keys are added makes a difference. For this reason, entering them in two different ways is a fundamentally different, non-interchangeable object type.
  - brundolf 4y ago
    You could preserve that information and still have the same native struct, since it only becomes relevant when iterating the keys