Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

overloaded functions bindings to gdScript #8987

Closed
toger5 opened this issue May 29, 2017 · 16 comments
Closed

overloaded functions bindings to gdScript #8987

toger5 opened this issue May 29, 2017 · 16 comments

Comments

@toger5
Copy link
Contributor

toger5 commented May 29, 2017

overloaded functions would be nice for the GDScript api.

how it currently works
If I bind multiple function with the same name and different parameter footprints, I just overwrite the previous binding.

use case example: #8981

@karroffel
Copy link
Contributor

I think that will be very hard as GDScript is dynamically typed.

@toger5
Copy link
Contributor Author

toger5 commented May 29, 2017

Okay I see. Very hard or almost impossible (if so you can close it. It would just be a fancy (aka not important) thing to have anyways)

@toger5
Copy link
Contributor Author

toger5 commented May 29, 2017

Oh I wasn't even aware that overloaded functions are not supported in gdScript itself (I though just bindings don't work)
And I also wouldn't know how it should work with being dynamically typed.

@raymoo
Copy link
Contributor

raymoo commented May 30, 2017

You could dispatch based on the arity of the function. You could also make it so that functions can declare the types they take as parameters and dispatch based on that.

@vnen
Copy link
Member

vnen commented May 31, 2017

An arity check could work, since GDSscript is quite strict about it when calling a function (except for a few built-in functions which accepts any number of arguments).

However, type-checking for the dispatch would likely cause many cases of unexpected behavior. Also, how would you choose if the actual type does not match any of the declarations?

@raymoo
Copy link
Contributor

raymoo commented May 31, 2017

You could have a "generic" function to fall back to (when it makes sense to have one), or just give an error if nothing matches.

@hubbyist
Copy link

hubbyist commented May 31, 2017

If implemented, default behaviour must be to give error about "function name defined but no matching argument list found" I think. Otherwise finding bugs will not be easy.

Since fallback functions are functions anyway trying to supply them by default for each function will make things complex (Which one is the base and which ones are the overrides?), so developer must be responsible to decide if it is acceptable to supply a default (base) function, IMO.

@raymoo
Copy link
Contributor

raymoo commented May 31, 2017

There is actually only one sensible way to decide which function is the fallback: a function is a fallback of another one if each parameter is either the same type as the non-fallback function, or is an unspecified type. Also at least one parameter that has its type specified in the non-fallback function should be unspecified in the fallback.

You can guarantee that the most specific function will be used if you sort the overloaded functions by number of parameter types and then check each one for a match, starting with the one with the most specified types and ending with the one with the least. A "fallback" function will always have less defined parameter types than the functions it is a fallback for, so will be checked later.

@raymoo
Copy link
Contributor

raymoo commented May 31, 2017

I spoke too soon actually, I thought of an ambiguous case. If you have func(int, string), both func(unspecified, string) and func(int, unspecified) would be valid fallbacks, and it's ambiguous which should be chosen since neither is a generalization of the other.

@toger5
Copy link
Contributor Author

toger5 commented May 31, 2017

How much additional work would it be to add typehints. So dwvelopers can make overloaded fucntions more specific by defining the type of each parameter.
I think errors when no function is found is the best solution.

@kubecz3k
Copy link
Contributor

I'm closing this one since there was no new interest in the discussion for 11 months...
In 3.1 we should have optional static typing, let's see first how it will be implemented and improve from that point.

@aaronfranke
Copy link
Member

@vnen Would function overloading be feasible to have in GDScript? Might be worth re-evalutating now that you've done all that work on Typed GDScript and warnings.

@vnen
Copy link
Member

vnen commented Aug 24, 2018

@aaronfranke the problem is that typing is optional, so it's not always possible to detect which function to call at compile time. Using a runtime dispatch would be quite bad for performance and could lead to ambiguities as discussed previously. Again, it's feasible if the distinction is only in arity and not in types, but I don't think it's worth it

If it needs to work with bindings as well (which was the original topic), it would need a big change in the core, then it would be even less worthy.

@ivanskodje
Copy link
Contributor

@akien-mga

Hello from 2021! 💯
Can we do something about this now that we have static typing support in GDScript? :)
I am dying to reuse function names with different parameters func uri(var uri: String), func uri(var uriBuilder: UriBuilder)

@Calinou
Copy link
Member

Calinou commented Apr 5, 2021

Can we do something about this now that we have static typing support in GDScript? :)
I am dying to reuse function names with different parameters func uri(var uri: String), func uri(var uriBuilder: UriBuilder)

As far as I know, there are still no plans to implement function overloading in GDScript since we don't know how to implement it in an efficient manner.

Also, discussion should continue in this proposal since this repository is now used for bug reports only.

PS: Please don't ping project maintainers without a good reason – their inbox is chock-full already 🙂

@raymoo
Copy link
Contributor

raymoo commented Apr 9, 2021

By the way, Common Lisp has had this feature forever (as multiple dispatch methods), so anyone looking into implementing this could check what CL implementations do to improve performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants