What has always bothered me about TypeScript are union types. If you have a function that receives a parameter such as ‘Dog | Cat’, you cannot separate it. For example:
type Dog = { bark: () => void }
type Cat = { meow: () => void }
function speak(animal: Dog | Cat) {
if (‘bark’ in animal) {
animal.bark();
} else {
animal.meow();
}
}
Okay, okay, I know you can filter using ‘in’ to see if it has methods, but in real life, in a company where you have a colleague (who is a golden boy) who writes over-engineered code with hundreds of interfaces of interfaces, you don’t want to spend time searching through the files to find every element that is in the union type.
Whereas in Rust it does:
struct Dog {
name: String,
}
struct Cat {
name: String,
}
enum Animal {
Dog(Dog),
Cat(Cat),
}
fn process_animal(animal: Animal) {
match animal {
Animal::Dog(dog) => {
println!(‘It is a dog named {}’, dog.name);
}
Animal::Cat(cat) => {
println!(‘It is a cat named {}’, cat.name);
}
}
}
I think TypeScript should add a couple of lines of code to the generated JavaScript to do something like:
type Dog = { bark: () => void }
type Cat = { meow: () => void }
function speak(animal: Dog | Cat) {
if (animal is Dog) {
animal.bark();
} else {
animal.meow();
}
}
The idiomatic way to do this in TypeScript is with discriminated unions. You’re basically just giving the type system an extra property that makes it trivial to infer a type guard (while also making the runtime check in the compiled JavaScript foolproof).
You don't even need that. The code exactly as presented acts as a discriminator. TypeScript is smart enough to handle that logic in the if block and know whether animal has been validated as Dog vs Cat. GP is complaining about a feature that already exists in TypeScript
I’m not at my computer so I can’t remember the exact behavior of this situation, but was OP more so referring to autocomplete abilities of typescript? I think they were saying, you first must know if the object barks or meows, you must first type that in in order to get the benefit of type checking and subsequent autocomplete conditional body, which is annoying when you are dealing with complicated types. It requires you to do some hunting in to the types, rather than using a piece of code more like an interface.
Well imo GP is fundamentally misunderstanding TypeScript. It's explicitly a structural language not a nominal one. It goes against the entire design philosophy of TS
It would have been a super reasonable reply to talk about the history of TypeScript, why fundamentally its types exist to retroactively describe complicated datastructures encountered in real world JavaScript. And why when TypeScript overstepped that by creating enums, which require code generation and not mere type erasure to compile, it was decided to be a mistake that they won't repeat.
But instead your rebuttal was pointing out that TypeScript can compile OP's example code, which OP presented as valid TypeScript that they disliked. I'm not defending their position, I'm just saying that it didn't appear you had even properly read their comment.
You're talking about adding a runtime feature. TypeScript doesn't do that anymore. It can't control what properties are on objects or add new ones - you do that yourself in the standard JavaScript portion of the language. TypeScript only lets you describe what's there.
As a sibling said, discriminated unions are they way to go here. You can also add custom type guard functions if you can't control the objects but you want to centralize the detection of the types, but it's better to let TypeScript do it itself so that you don't mess something up with a cast.
type A = { bark: fn, meow?: never } | { bark?: never, meow: fn }
type B = { species: "dog", bark: fn } | { species: "cat", meow: fn }
or use instanceof with a class
What always bothers me with enums, sealed-types, etc is that I can't compose a new ad-hoc set based on elements of someone else's enum. You can make one using the other but not the other way around, TypeScript's is more general.
You can literally do what your generated example does using a type guard. You can also use method overloaded signatures if you dont want to expose your API consumers to union types.
Some years ago a chinese company released a phone with 2 screens, one typical mobile screen and other side a e-paper screen.
But I don't remember what happened, but unfortunately this idea didn't succeed.
There is not a old socket from the toilets in the old trains (maybe trains are 60 years old...more or less 1970) in Spain. This sockets are near the mirror and I think that this sockets were for old electic shavers.
I remember that years ago when the android phones started there was a app for flash games....I don't remember the name the app (and maybe this app does not run in current android phones)
There was a browser-streaming app that would play them remotely, can't remember what it was called.
There was an official plugin by Adobe on Android but it was awful, I remember watching them showcase it at a conference it was tragic even with their handpicked and simple example.
Then there was a transpiler that produced native apps from Flash, this was actually pretty good but Apple then banned transpiling which killed its viability entirely, six months later they un-banned transpiling but the damage was done.
But on the plus side, Apple got to monopolize transaction fees in Flash games like Farmville for nearly two decades!
The problem with these engines is you need to become familiar with both Godot as well as the point&click extension making them less suited as a first adventure authoring platform.
Because Nint€ndo or $ony (and others game companies) have a big problem, their old games are awesome and if the people can play these games, then the people will be happy and will not need new games or new sagas.
Because the problem is not the people playing old games, the real problem is the people will not pay for new games
And we know that these companies have army of lawyers (and "envelopes" to distribute among politicians) to change the laws and make illegal something that is not illegal.
I have very little sympathy for these companies. They make access to these titles difficult if not impossible. Preservation matters and they have no interest in anything but the bottom line today.
type Dog = { bark: () => void }
type Cat = { meow: () => void }
function speak(animal: Dog | Cat) {
}Okay, okay, I know you can filter using ‘in’ to see if it has methods, but in real life, in a company where you have a colleague (who is a golden boy) who writes over-engineered code with hundreds of interfaces of interfaces, you don’t want to spend time searching through the files to find every element that is in the union type.
Whereas in Rust it does:
struct Dog { name: String, }
struct Cat { name: String, }
enum Animal {
}fn process_animal(animal: Animal) {
}I think TypeScript should add a couple of lines of code to the generated JavaScript to do something like:
type Dog = { bark: () => void }
type Cat = { meow: () => void }
function speak(animal: Dog | Cat) {
reply