v76(d): Possible Function Overloading Bug

Monkey Forums/Monkey Bug Reports/v76(d): Possible Function Overloading Bug

ImmutableOctet(SKNG)

(Posted 2013) [#1]

I'm not entirely sure what's going on here, but if I make an overload for a function which is in another module, and call that function from my function overload, I get an "Unable to find overload for InsertFunctionNameHere(ArgumentsHere)" error.

Is this normal behavior for Monkey's compiler, or is this unintended? I'm asking because I wanted to make an overload of the 'DrawRect' function for a project of mine, but all the overload is supposed to do is wrap the regular implementation.

After looking into it deeper, it seems to completely forget that Mojo's version of 'DrawRect' exists when I make an overload for it; I can't even call it from 'OnRender'.

Assuming this isn't a bug, and it's supposed to forget about all imported public functions with the same title, could you add something about this to the documentation? (Assuming it isn't somewhere in there already)

therevills

(Posted 2013) [#2]

In different modules I think you need to state the module you are wanting to call: mojo.DrawRect(x,y,h,w)

ImmutableOctet(SKNG)

(Posted 2013) [#3]

That fixed it, but it's still really weird. I have to use 'mojo.DrawRect' every time I want to call 'DrawRect', just so I can use one overload which doesn't even conflict with anything. And then there's aliases, but using one of those gives me errors because the function is already called 'DrawRect'.

And then if I have my wrapper function in another file/module, I have to call it with its module-name. Well, unless I use aliases, but then I have the problem of using 'mojo.DrawRect', so either way it's a double-edged sword.

This sounds like some kind of weird compiler limitation to me, I'm just wondering if it's by-design at this point.

Gerry Quinn

(Posted 2013) [#4]

I tend to use formats like "MyDrawRect" for clashing function names for this reason.

ImmutableOctet(SKNG)

(Posted 2013) [#5]

Okay, this is definitely a fundamental problem. I have two classes, the first is just a normal class, and the second is derived from the first class. The problem is, I can't make an overload of one of the methods found in the super-class; needless to say, this is an issue.

Mark, this is something higher-priority than even something like a 'Protected' directive, and should definitely be looked into immediately. Well, either that, or some kind of official clarification on this being purposeful. You know, after thinking about it further, having this as some sort of overload-locking option via a class-keyword would be ideal.

This and the way 'Public' and 'Private' work remind me of how things usually go with Blitz-family languages, where the problem isn't fixed until the language's successor. BlitzMax essentially gave us proper classes and modules, but the modules weren't fully integrated (I'm actually a fan of this idea), and Monkey gave us generics/templates, and almost complete modularity, but overloads are problematic, and 'Protected' is still needed. The list goes on (Pointers, 'Extern', collections, supported platforms, etc), but you get the idea. And because of this pattern, this makes me skeptical if limitations like these will ever be solved in Monkey itself.

Gerry Quinn

(Posted 2013) [#6]

I'm not sure I understand the problem here. The following works:

Strict

Function Main:Int()
	Local a:A = New A()
	a.x = 10
	Local b:B = New B()
	b.x = 10
	a.Modify( 4 )
	b.Modify( 4 )
	Print a.x
	Print b.x
	Return 0
End

Class A

	Field x:Int
	
	Method Modify:Void( param:Int )
		x += param
	End	
	
End


Class B Extends A
	
	Method Modify:Void( param:Int )
		x *= param
	End
	
End

Output is 14, 40

Are you trying to make an overload with the same parameters but a different return type? AFAIK many languages disallow this.

Edit: I see, the same problem occurs when you have a method with different parameters. Which most languages do allow.

I agree that this would be nice to have, though I would much prefer a Protected directive...