This is probably a horrible idea, but just fleshing out a possibility. Instead of one implementation for a method name, we could potentially support multiple implementations with the same name, using this technique:
export class Foo {
method(a: number){
// 1st implementation
}
method(a: boolean){
// 2nd implementation
}
method(a: string, b: boolean, c?: number){
// 3rd implementation
}
}
So the above would transpile to:
const symbols = [
Symbol('private1'),
Symbol('private2'),
Symbol('private3')
];
export class Foo {
[symbols[0]](){
// 1st implementation
}
[symbols[1]](){
// 2nd implementation
}
[symbols[2]](){
// 3rd implementation
}
method(){
// this gets generated by tsc engine
if(typeof arguments[0] === 'number'){
return this[symbols[0]].apply(this, arguments);
}
if(typeof arguments[0] === 'boolean'){
return this[symbols[1]].apply(this, arguments);
}
if(typeof arguments[0] === 'string'){
return this[symbols[2]].apply(this, arguments);
}
throw 'no match'
}
}
probably a terrible idea but just a thought.
I think the real obstacle is the matching would be fuzzy, and fuzziness does not really make for predictable software. You could require a unique first argument, however, using some construct that I don't know exists:
export class Foo {
method('unique string a', a: number){
// 1st implementation
}
method('unique string b', a: boolean){
// 2nd implementation
}
method('unique string c', a: string, b: boolean, c?: number){
// 3rd implementation
}
}
it's nice for APIs where you don't need 3 different names for the same operation. But then requiring a unique string as a first arg somewhat defeats the purpose.
Duplicate of #5407 and others (e.g. #19859, #6936, etc.).
You should a) really search before you open an issue and b) follow the issue template instead of ignoring it. Why did you ignore the issue template?
@kitsonk I did it on my phone
@kitsonk please pay attention, those issues you mentioned are for _operator_ overloading, not _method_ overloading. I just realized that I put the wrong one in the title so I fixed it.
Again, real method overloading has been covered before. #3442 and others (e.g. #10696, #11702, #12041, etc.).
Why didn't you search and why didn't you follow the issue template?
@ORESoftware one thing to think about is whether function overloading would really not have been suggested sometime in the previous thirty thousand issues
It's also in the FAQ under "Common Feature Requests" https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests
I just thought my implementation was fun and I wanted to share it with the world
medium.com 馃槈
Most helpful comment
Again, real method overloading has been covered before. #3442 and others (e.g. #10696, #11702, #12041, etc.).
Why didn't you search and why didn't you follow the issue template?