Small bug with function and method names

Monkey Forums/Monkey Bug Reports/Small bug with function and method names

ImmutableOctet(SKNG)

(Posted 2014) [#1]

I wrote a class a while ago which has the same name for a function as it does a method. But, Monkey is unable to determine if I'm using a method or a function despite obviously using the function.

Basically, I have a generic class called 'AbstractVector', which has the following method:

' (The 'FTV' and 'STV' arguments are for temporary vectors):
Method DotProductNormalized:T(V:Vector<T>, FTV:Vector<T>=Null, STV:Vector<T>=Null)

This works just fine, until we get to the function:

Function DotProductNormalized:T(V1:Vector<T>, V2:Vector<T>)

I'm not sure if this is by-design or not, but if I try to call the following function (Which is obviously outside of the class), I get an error:

Function DotProductNormalized:Float(V1:Vector<Float>, V2:Vector<Float>)
	Return AbstractVector<Float>.DotProductNormalized(V1, V2)
End

The 'Vector' type you're seeing is an interface which 'AbstractVector' implements.

So, is this a design choice for Monkey? Because it's rather weird for me. I'm assuming this is a con by-extension, due to the ability to do this the other way. (Which actually makes sense, as opposed to this)

I'm of course referring to the following:

' Local variable(s):

' These types are also defined in my module:
Local V:= New Vector2D<Float>()
Local V2:= New Vector3D<Float>()

' Set the values for the vectors:
V.X = 10.0
V.Y = 100.0

V2.X = 15.0
V2.Y = 30.0

' This will call the function instead of the method.
Local Product:= V.DotProductNormalized(V, V2)

' Output to the console.
Print(Product + ", V: " + V + ", V2: " + V2)

And I'd assume if 'Vector2D' reimplemented the function version of 'DotProductNormalized' that it would call that.

So, what's your take on this. Of course, I already know the work-around for this issue, but it struck me as odd that this even happens.

The current version of the module I'm talking about is on github, but it's not up-to-date, so it should compile just fine. The version I'm currently working on does compile after my small fix, but I haven't uploaded it yet. (Which isn't even needed for that version)

marksibly

(Posted 2014) [#2]

> I'm not sure if this is by-design

It was 'by design' - mainly to keep things simple for my first attempt at implementing overloading in a compiler! I may be able to hack around it, but it's currently low priority.

I have a MUCH clearer picture of how all the overloading stuff should be done now, but it really requires massive rewrites of parts of the compiler. As with a lot of the overloading issues, I've sort of been torn between hacking each issue case-by-case, and just throwing out the whole lot and starting from scratch...maybe one day.