JSPPE5024: No overload for `function' matching signature `function(...)' Description We tried to call a function with the wrong argument types. Causes Function call with incorrect arguments Example: 12345678import System; int add(int a, int b) { return a + b;} int result = add("1", "2"); // hereConsole.log(result); There is only one function signature for the 'add' function: int add(int, int). However, our function call attempts to call with the signature int add(string, string). The fix here is to use the correct data type in the arguments of our function call. Fix: 12345678import System; int add(int a, int b) { return a + b;} int result = add(1, 2); // call 'int add(int, int)' insteadConsole.log(result); Forgetting to define the function or function overload Example: 1234567891011import System; int[] concat(int[] a, int[] b) { return a.concat(b);} string[] a = [ "a" ];string[] b = [ "b" ];string[] result = concat(a, b); // here Console.log(result); There is only one function signature for the 'concat' function: int[] concat(int[], int[]). However, it seems we wanted functionality that enables us to also concatenate string arrays. Thus, we need to use function overloading or generic programming. Without using generics, a simpler fix would be to define a function overload that accepts string[] arguments and returns string[] as a result. Fix: 1234567891011121314import System; int[] concat(int[] a, int[] b) { return a.concat(b);}// Fix by overloading the 'concat' functionstring[] concat(string[] a, string[] b) { return a.concat(b);} string[] a = [ "a" ];string[] b = [ "b" ]; Console.log(concat(a, b)); Refactoring Example: 123456789101112131415161718import System; // Old implementation/*string[] concat(string[] a, string[] b) { return a.concat(b);}*/// Refactored implementationint[] concat(int[] a, int[] b) { return a.concat(b);} string[] a = [ "a" ];string[] b = [ "b" ];string[] result = concat(a, b); // here Console.log(result); We may have refactored our code and changed our function signatures. In the above code, we changed the 'concat' signature from string[] concat(string[], string[]) to int[] concat(int[], int[]). The fix is to update all calls of the refactored function to reflect the updated argument types. Fix: 12345678910111213141516171819import System; // Old implementation/*string[] concat(string[] a, string[] b) { return a.concat(b);}*/// Refactored implementationint[] concat(int[] a, int[] b) { return a.concat(b);} // Fixed:int[] a = [ 1, 2, 3 ];int[] b = [ 4, 5, 6 ];int[] result = concat(a, b); Console.log(result); Constructor Call Example: 12345678910class Page{ Page(string title) { this(100); // here } Page(string title, string url) { }} Page page = new Page("My Page Title"); There are no constructors matching Page(int) signature. The valid constructor signatures are Page(string) and Page(string, string). In order to fix this, we need our argument types to match the valid constructor parameter types. Fix: 12345678910class Page{ Page(string title) { this(title, "http://www.example.com/page.html"); // call 'Page(string, string)' } Page(string title, string url) { }} Page page = new Page("My Page Title"); Arrays (and Dictionaries and other containers) Example: 1234string[] names = [];names.push("Roger");names.push("Anton");names.push(100); // JSPPE5024: No overload for `System.Array<string>.push' matching signature `System.Array<string>.push(int)' at line 4 char 0 System.Array<T> is a generic class. Therefore, it contains methods (like push) that depend on type arguments. In this case, the System.Array<T>.push method has the signature int push(T element). Since the array was passed the string as its generic argument, push also expects a string argument. Therefore, we should only be pushing strings. If we wanted an integer array, we could declare a new array (e.g. int[] or System.Array<int>. If we wanted a mixed type array, we could declare System.Object[] or System.Array<System.Object> for internal types. If we wanted a mixed type array for external types, we can declare the array with var or System.Array<external>. However, we cannot create an array of both internal and external types unless all the internal types being represented also have a conversion to external; in this case, it would be best to provide conversions for the internal types to external (e.g. using the toExternal design pattern). Fix: 1234string[] names = [];names.push("Roger");names.push("Anton");names.push("Samantha"); // Pass an actual name (string) rather than an integer See Also Function Overloading Share HTML | BBCode | Direct Link