Re: reasons for learning typescript
@7 not going to go into monkey patching, because I don't have experience doing it in js, so maybe that is the case, but I suspect that even for that you can avoid type casting. the other two cases, you can avoid type casting altogether.
for having a hierarchy of event types, where the type of event is determined by the value of a member. like for one type of event, the member "kind" is "io" and for another it ight be "time" and that determines what other members it has, then there is no need for type casting to get at those members specific to its subtype. consider this simple event hierarchy:
type BaseEvent = { message: string }
type IOEvent = BaseEvent & { kind: 'io' }
type TimeEvent = BaseEvent & { kind: 'time', timestamp: number }
type MyEvent = IOEvent | TimeEvent
then we can branch on which type of event it is without any type casting like this:
function processEvent(e: MyEvent) {
// available for any event from BaseEvent
e.message
if (e.kind == 'time') {
// in this scope typescript knows which event subtype it is
e.timestamp //only available since it is TimeEvent
}
}
for the second case, when you have unknown json coming in and you need to verify it has the members you expect it to have, then you can use a type guard where you check it has all the members of the type you expect. this can be quite verbose, so I like to use a json decoder library that makes this easy. it's @mojotech/json-type-validation
if you are expecteing this type:
type User = {
name : string,
age : number
}
you would define a decoder for it like:
const userDecoder = object({
name : string(),
age : number()
})
and use it like this:
function processUser(unverifiedUser: unknown) {
const user: User = userDecoder.runWithException(unverifiedUser)
// throws an exceptoin if doesn't conform
}
there are other ways to run the decoder, in case you want to handle the unhappy path more gracefully, but that is the basic idea. by deciding not to do typecasting, we were forced to take a more principled approach to verifying incoming json is really the type we believe it is and so if it doesn't conform to our beliefs we learn about it right at the edge of our app with the external endpoint. this makes it much easier to debug if that happens. the alternative is we cast the incoming any from json.parse() to our type and then it causes some type error farther down the line, which is much harder to diagnose.
as to your other points. why did typescript developers put it in? sorry to anser a question with a question, but why did other language developers put null into their language when it is widely regarded as the billion dollar mistake in programming? as to typecasting, my guess is that a lot of js developers (probably not you) are really impatient and care more about their code running than it actually being correct, so they put it in there as an unnecessary backdoor.
also it isn't exactly true that all static typed languages have type casting. weakly typed ones like C and Java do, but strongly typed languages like Rust and Haskell don't, except as escape hatches that are clearly marked as unsafe and nuclear as they very much are.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
