Bug with overloading?

Monkey Forums/Monkey Programming/Bug with overloading?

Skn3(Posted 2013) [#1]
Is this a bug?

(currently it fails and warns that it cant determine which overload to use)

Tested on 76a in glfw.




SLotman(Posted 2013) [#2]
Does it work if you do:

Test(1, (item) New SuperItem) ?

My guess is that overloading will always try to match all parameters, and by passing a SuperItem instead of an Item, it can't find the correct one.

Don't know how Java or C# would treat this, but I guess that's what's happening.


Goodlookinguy(Posted 2013) [#3]
It's not a bug in Mark's eyes. Take a look at this thread http://www.monkeycoder.co.nz/Community/posts.php?topic=3839

Just a quick note, the reason your code is failing is because of the integer '1'. It can't decide whether or not to take it as is or to convert it to a string.

I still believe this is a bug.

Edit: Oh, apparently I'm wrong, which is interesting considering that my tests have shown the integer to be the problem. I digress through, whatever, I just name a function to something more precise.


marksibly(Posted 2013) [#4]
> My guess is that overloading will always try to match all parameters, and by passing a SuperItem instead of an Item, it can't find the correct one.

This is correct - the problem is not the '1', but the 'item' param.

If there are multiple possible matches, but no exact match, Monkey will complain. If there is only one possible match - even if it's inexact - you're OK.

This is more restrictive than some other languages (which compute 'distances' between types) but IMO simpler/clearer.


Skn3(Posted 2013) [#5]
Ok fair enough. Its not a major problem but it did confuse for a a little bit. Perhaps additional explanation could be added to the error? Something just to hint to people about it.

"no exact match found, try manually casting your values"

or something.