Re: reasons for learning typescript
One reason is monkey patching an already typed TypeScript library, especially when trying to monkey-patch private functions/methods.
TypeScript will, for obvious reasons, not allow you to do this, because the method/function is private. You could now argue "but you could fork the repository and create do whatever you want in this fork", but since monkey-patching is one of the advantages of scripted languages like JS and Python, there is no reason to fork a multiple-thousand lines repository if you need to replace one function with three lines of code.
Then there is class inheritance / class enhancement. Consider an event system, where an event knows its type via a constant and some other information that is generic for all events. And then there are subclasses for all the different event types with more attributes which are specific for those events. Now you want to create a list of events and will therefore use the generic event type, because otherwise you couldn't store all the events in one list. Now, when you're processing this list and want to handle the events and want to access information stored in a specific event, you'll need to cast it, because this information is not generic for all events but specific to this single event, and without knowing that TypeScript is actually looking at an event that is specifically this subclass of event, it won't let you access that attribute of the class.
A more common example would be the first-time type specification of incoming data, e.g. when writing a REST API. The data that is coming in from the browser or whatever is asking the end point can only be classified as any by the point it comes in, because its not yet safe if it fulfills our requirements in regards to the API parameters. Therefore, what you usually do is validate the request parameters. Are all of those there? Do they have the correct type? If no, can I safely cast them, depending on if you actually want to do this, e.g. casting '1' to 1 is possible, and maybe you want to do this for a more flexible API design. And as soon as you did and the incoming data is fine with your API, you can tell the TypeScript compiler that you're actually working with whatever object you defined beforehand that contains all the fields of your API request object so that you can pass that on to actually implement the logic of your API, convert it into a DTO or domain object and so on.
Those are the reasons that come to my mind right now. There might be more though.
In the end, type casting stays the swiss knife that allows us to go to the compiler and say "I know that you're thinking that this object is of type x, but I'm telling you that it is actually of type y, and I know better than you, so shut up already!". That such a measure always involves some risk is obviously correct, but there is a reason that this feature exists. If it was really that bad and everyone should avoid it at all cost, why would the language developers bother with implementing it in the first place? And I mean, all of them. You don't find any statically typed language without type casting out there. Its of course fine to avoid it, there is nothing wrong about it, but there are just the same reasons not to.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
