SkriptLang
Function overloading
Description
Adds function overloading.
Function overloading allows two functions with the same name to be registered, as long as
- their parameter types differ, or
- the amount of arguments differ.
An example:
function overloaded(x: int, y: int) :: int:
return 1
function overloaded(x: int, y: int, z: int) :: int:
return 2
function overloaded(x: text, y: text) :: int:
return 3
function overloaded(x: text, y: int, z: int) :: int:
return 4
FunctionRegistry
Description
To accomplish this, a new FunctionRegistry class has been added, which is only visible to the function package. This holds all signatures and functions by a namespace. A namespace is either the global namespace, for global functions, or a script, in which local functions can be registered.
Functions and signatures are differentiated by a FunctionIdentifier, which holds the function's name and the types of its arguments.
Why are the methods in the Functions class not deprecated?
In the future, I plan on adding function parameter specification by name, e.g. location(x=10,y=10,z=10,world="world"). When that has been added, there will, in my opinion, be enough future-proofing, thus the FunctionRegistry class can replace the Functions class' functionality. Overloaded functions will not be visible to Functions.
Behaviour
When a function has an ambiguous type in one of its arguments, it will attempt to match based on the other arguments.
Therefore, overloaded(1, {_none}) and overloaded({_none}, 2) will still call the correct overloaded, as the function overloaded(int, int) is the only one that can be matched here.
When a function has multiple implementations, and it can't be decided which one to use (due to variables for example), a parse-time error will be thrown.
Like other languages, functions cannot be differentiated by return type.
Target Minecraft Versions: any Requirements: none Related Issues: #1185, #2993
"Try clarifying the type of the arguments"
How?
I was thinking literal type clarification but I guess that's only for literals
"Try clarifying the type of the arguments"
How?
I was thinking literal type clarification but I guess that's only for literals
You could evaluate at runtime, which could be very flexible but also possibly confusing to users in some cases. store the candidates and pick at runtime
I think I prefer a more limited system that errors at parse time over one that may cause runtime errors. Wdyt?
