Call and Overloading bug?

Say I gave 2 overloaded methods:

Sub aMethod
and

Func aMethod as boolean

Then you can use:

Dim X as Boolean = aMethod
Or

aMethod

In code without an error…

But if you try to do:

Call aMethod

The compiler complaines that it can’t tell which method you want … But since the code explicitly shows you want the version that returns a value, shouldn’t the compiler be able to distinguish between the 2 methods?

How I ran into this…

It was with an SQLite DB subclass with Connect methods that set enable foreign key support. The difference between the two is that one method returns a boolean (as in the classic Recordset API) and the other raises an exception if connect fails. I was updating old code with this subclass that had code with

Call DB.Connect
and unexpectedly got the error

I do not think method overloading works based on return type. That would be nice, but never worked and I don’t think it was designed to work. It only works on overloaded parameters.

In general, if something should return a value, you should handle it, no? If it is of no value, then don’t return it?

The ‘Call’ expression works with any methods, regardless of whether or not there is a return value.

The code doesn’t explicitly say you want the version thats a function and returns a value.
It explicitly says I don’t care about the return value - thats what call does.
And now there are two possible methods that can be called (you can call a sub as well).

Return types are NOT part of the signature. Only the name & parameters.
But in this case it would not matter since CALL explicitly ignores return values.

[quote=190828:@Jeremy Cowgar]I do not think method overloading works based on return type. That would be nice, but never worked and I don’t think it was designed to work. It only works on overloaded parameters.

[/quote]

I keep forgetting that because my intuition keeps telling me the signatures are different when I look at the method header!!!

Thanks,

  • Karen

[quote=190830:@Norman Palardy]Return types are NOT part of the signature. Only the name & parameters.
But in this case it would not matter since CALL explicitly ignores return values.[/quote]

I should and really did know these things… but in both cases I keep forgetting them because it’s not how I intuitively think things SHOULD work!!!

Thanks

  • Karen

There are some languages where return type is considered part of the signature.
And others you might have heard of that don’t include it - Java, C#, Xojo

Never used Java or C#. While I have coded in a number of different languages over the years Xojo is the only OO language I have significant experience with.

It’s just that it’s hard for me not to think of the whole method header definition the IDE as the ‘signature’ when you see it in the IDE… That and I think age is starting into affect my memory…

Now where did I leave the house keys and why did I come into this room? :wink:

  • Karen

The point wasn’t that you had used them - just there are other popular languages that do not include return type as part of the signature.
There are other popular ones that do.

There seems to be no “right answer” as far as this is concerned and there are pro’s & cons to each approach