Typescript is a type system built on top of Javascript and its only purpose is to secure your application by applying strong type security.
Thanks...
For further actions, you may consider blocking this person and/or reporting abuse
I think without real support for defining implementations of overloaded functions, you shouldn't overload functions at all. It's much better for maintainability to create different names for different things instead of overloading the same name for totally different signatures.
Yeah, that's what I liked about C# (first class support of overloading). That is: If you have a different signature, then you will also have code in your method or function body that corresponds directly it. To me, I always found that easier to comprehend.
That's why I might still prefer using a union type here, i.e.
string[] | stringwhere you join the types together with|, and just ensure that whatever you define is generally compatible with that. You still have to implement some logic, but it's probably a little simpler than if you were to change or omit middle parameters. I just found it easier to comprehend when reading it, especially if it's someone else's code.I know it's very broadly speaking, so that's just my opinion and I understand each use case may vary. 😅 It's cool to see this is possible, though.
For some use case, I agree with you but for other, I don't want to create multiple functions.
My exemple is maybe poorly chosen but it gives the idea of what function overloading can archive.
Yes, I use function overloading with languages that actually support it, such as C++. However, the "supported in signature but not for implementation" doesn't cut it.
Yes I agree with you. Coming from java, it was hard at first to understand this. But for lib author, that's very neat.
Function overloading is definitive a feature I am missing in JS. Thank you for your post!
It is actually now possible in JS using JSDoc together with the new TS 5.0: dev.to/voxpelli/typescript-50-for-...
I learnt a lot of new concepts in this article.
Thanks for mentioning it. That's great to hear 🙏
It has good explanation with example, thank you for the knowledge
If you are dealing with classes, overloading the constructor is quite helpful. But for pure functions I rather let TS define them and then validate the result myself or use "as" if I'm confident of the outcome. This will be JS after all.
of course everything will be JS at the end. But TS is here to help. When creating library, it's always nice to have autocomplete. My exemple is very simple, but sometimes, functions are more complicated.
And for the return type, I prefer to have the correct return type than using the "as" keyword. When everything is your own implementation, why not. But when working on teams or npm lib, function overload is an awesome feature.
One should be wary of the performance costs of this kind of strategy. While I understand that performance is not often a primary concern of front-end web development, this level of overloading does beg the question of how many additional stubs must be generated by the JIT compiler in order to make this kind of type flexibility possible.
you mean performance at compile time? since all types are removed at runtime. I don't think that a good argument not to use them.
No, not performance at typescript compilation.
The V8 JIT must consume more memory to support polymorphic functions because stub signatures are generated to account for all type possibilities.
Then if the arguments received at runtime change too frequently, the TurboFan optimizing compiler may fail to heat up your operations.
I didn't mean to suggest that polymorphism by way of overloading should be totally avoided. Just a friendly "Here may be dragons."
Ok thanks for the explanation. Didn't know that.