4 ms·

It makes a number out of a number. Type signature isn’t supposed to explain the implementation, just the interface.

hombre_fatal 6y ago
Something you run into when adding Typescript annotations to existing JS / libraries in the wild is when the signature turns out to be: function transform(a: number | string): number | "" | false And it's usually all by accident. And it works because in practice it's used with a `if (!transform(x))` check. Static typing doesn't just tell you what's going on, but it also helps you keep your implementation honest with your intent. It's also why it's a good habit to annotate top-level functions instead of relying on their inference.
- realharo 6y ago
  This is especially true with `| undefined` helping address the billion dollar mistake.
- ygra 6y ago
  You can sometimes use overloads to make it better: function transform(a: number): number function transform(a: string): false function transform(""): "" Depending on how predictable the output is from the types, of course. But for many things it works better than just using union types everywhere.
2019-nCoV 6y ago
Exactly. The parent post claimed: > Once you are able to comfortably read type signatures, it is trivial to see what a function is supposed to do Typing gives minimal insight into what a function actually "does". The solution is intention revealing naming, available in all languages.
- int_19h 6y ago
  Naming is where it starts, but the type signature also carries plenty of information it it, especially once you get to non-primitive types.
- gavinray 6y ago
  It doesn't really matter what the function does, if the input and output signatures are Interfaces or Types that have been annotated with JSDoc. You see "Put an object with these properties and types in, get an object of this shape back out." The beauty of types is in this black-box, abstract behavior. You, as a library author, can define an Interface/Contract for the behavior of something completely abstractly, and other people can all use each other's implementations or contribute original ones because they obey the contract. Think about an "Abstract class File, which implements open, read, and write." There are a lot of ways you could write these methods but if your type signatures match the inputs and outputs they're all equally valid with predictable behavior. Design by contract is a beautiful thing.
  - keymone 6y ago
    it matters when the function isn't pure but otherwise contracts are good.

Something you run into when adding Typescript annotations to existing JS / libraries in the wild is when the signature turns out to be: function transform(a: number | string): number | "" | false And it's usually all by accident. And it works because in practice it's used with a `if (!transform(x))` check. Static typing doesn't just tell you what's going on, but it also helps you keep your implementation honest with your intent. It's also why it's a good habit to annotate top-level functions instead of relying on their inference.

realharo 6y ago
This is especially true with `| undefined` helping address the billion dollar mistake.
ygra 6y ago
You can sometimes use overloads to make it better: function transform(a: number): number function transform(a: string): false function transform(""): "" Depending on how predictable the output is from the types, of course. But for many things it works better than just using union types everywhere.

2019-nCoV 6y ago

Exactly. The parent post claimed: > Once you are able to comfortably read type signatures, it is trivial to see what a function is supposed to do Typing gives minimal insight into what a function actually "does". The solution is intention revealing naming, available in all languages.

int_19h 6y ago
Naming is where it starts, but the type signature also carries plenty of information it it, especially once you get to non-primitive types.
gavinray 6y ago
It doesn't really matter what the function does, if the input and output signatures are Interfaces or Types that have been annotated with JSDoc. You see "Put an object with these properties and types in, get an object of this shape back out." The beauty of types is in this black-box, abstract behavior. You, as a library author, can define an Interface/Contract for the behavior of something completely abstractly, and other people can all use each other's implementations or contribute original ones because they obey the contract. Think about an "Abstract class File, which implements open, read, and write." There are a lot of ways you could write these methods but if your type signatures match the inputs and outputs they're all equally valid with predictable behavior. Design by contract is a beautiful thing.
- keymone 6y ago
  it matters when the function isn't pure but otherwise contracts are good.