[RESOLVED] Renaming of overloaded functions from .NET

[SearchingDataOnly]

I often need to translate some .NET code to VB6 code. Function overloading is allowed in .NET. I'd like to know how to rename these overloaded functions in VB6? E.g:

Function GetProperty(ByVal name As String, ByVal returnType As Type, ByVal types() As Type, ByVal modifiers() As ParameterModifier) As PropertyInfo

Function GetProperty(ByVal name As String, ByVal returnType As Type, ByVal types() As Type) As PropertyInfo

Function GetProperty(ByVal name As String, ByVal types() As Type) As PropertyInfo

Function GetProperty(ByVal name As String, ByVal returnType As Type) As PropertyInfo

Function GetProperty(ByVal name As String) As PropertyInfo

Function GetProperty(ByVal name As String, ByVal bindingAttr As BindingFlags) As PropertyInfo

Function GetProperty(ByVal name As String, ByVal bindingAttr As BindingFlags, ByVal binder As Binder, ByVal returnType As Type, ByVal types() As Type, ByVal modifiers() As ParameterModifier) As PropertyInfo

Currently, I can only rename the above functions to
GetProperty,
GetProperty2,
GetProperty3,
GetProperty4,
GetProperty5,
GetProperty6,
GetProperty7.

I wonder if there is a better way to name them. Thanks.

[Zvoni]

Function GetProperty( _
ByVal name As String, _
Optional ByVal returnType As Type, _
Optional ByVal types() As Type, _
Optional ByVal modifiers() As ParameterModifier, _
Optional ByVal bindingAttr As BindingFlags, _
Optional ByVal binder As Binder) As PropertyInfo

Function-Overloading is done if the language doesn't support Optional Parameters (as i know from Pascal, no idea in Dot Crap)
Default-Values for the Optional Parameters can be applied in the Function-header

EDIT:
I wouldn't be surprised, if in the original source-code for, say,

Function GetProperty(ByVal name As String) As PropertyInfo

there is only one line of code, like (in vb6-Syntax!!!)

Function GetProperty(ByVal name As String) As PropertyInfo
   GetProperty=GetProperty(Name, DefaultBindingFlag, DefaultBinder, DefaultReturnType, DefaultType, DefaultParameterModifier) 'Call to overloaded function, passing "Name" as is
End Function

EDIT2:
Was just reading up on this.
In .NET Function overloading is used to implement Polymorphism
https://www.geeksforgeeks.org/c-shar...d-overloading/

[SearchingDataOnly]

Hi Zvoni, thanks for your reply.

If Optional-Parameters is used, the incoming order of VB6 parameters is inconsistent with the incoming order of .NET's original functions.

[Niya]

Currently, I can only rename the above functions to
GetProperty,
GetProperty2,
GetProperty3,
GetProperty4,
GetProperty5,
GetProperty6,
GetProperty7.

I wonder if there is a better way to name them. Thanks.

This is basically what modern compilers do internally to implement overloading so you're already on the right track.

[Zvoni]

Hi Zvoni, thanks for your reply.

If Optional-Parameters is used, the incoming order of VB6 parameters is inconsistent with the incoming order of .NET's original functions.

Only if you translate the .NET-Function-Calls "1 to 1", then yes, but also in regards to Niya's answer:

What's easier?
Deciding which of the 8 Functions to explicitely call (depending on the Parameters, and their order, type, whatever),

or to
Call GetProperty("SomeName",SomeReturnType,,SomeModifier,,SomeBinder)

Bottom Line: There is no "easy" way to "literally" translate to vb6, independent that some .NET-Compiler is doing this and that behind the scenes

You have to find out from the Source-code if it's doing Polymorphism (as in "really" different Functionality depending which overloaded Function is called) or if it's "emulating" optional Parameters.

My Money is on the Optional Parameters

[SearchingDataOnly]

This is basically what modern compilers do internally to implement overloading so you're already on the right track.

Hmm, glad to hear that. It's just that the naming is so ugly.

[SearchingDataOnly]

Only if you translate the .NET-Function-Calls "1 to 1", then yes, but also in regards to Niya's answer:

What's easier?
Deciding which of the 8 Functions to explicitely call (depending on the Parameters, and their order, type, whatever),

or to
Call GetProperty("SomeName",SomeReturnType,,SomeModifier,,SomeBinder)

Bottom Line: There is no "easy" way to "literally" translate to vb6, independent that some .NET-Compiler is doing this and that behind the scenes

You have to find out from the Source-code if it's doing Polymorphism (as in "really" different Functionality depending which overloaded Function is called) or if it's "emulating" optional Parameters.

My Money is on the Optional Parameters

Yes, many times we can't find the best of both worlds.

[Zvoni]

Yes, many times we can't find the best of both worlds.

Would have to disagree in this particular case.
I repeat: It depends what the underlying source-code is doing.

In your example, all (overloaded) Function-Signatures have in common the Parameter "name".
Note: There is one "version" only having that one single parameter.
That's a strong indicator, that the overloads are emulating Optional Parameters, and in vb6 there is a Syntax for Optional Parameters

BUT:
What you can do with Function overloading is this (i'm using vb6-syntax)

Function DoSomething(ByVal Long1 As Long, ByVal Long2 As Long) As Long
  DoSomething = Long1 + Long2
End Function

Function DoSomething(ByVal Long1 As Long, ByVal Long2 As Long, ByVal Long3 As Long) As Double
  DoSomething = (Long3 - Long2) / Long1   'Yes, yes, check if Long1 = 0 blablablabla
End Function

That would be (in a way) Polymorphism, because dependent on the Parameters, you have different functionality
And honestly? In this case i would have different (especially descriptive!!) Function-Names, too, completely avoiding the confusion, overloading is introducing to this scenario
Because in vb6 the Alternative would be

Function DoSomething(ByVal Long1 As Long, ByVal Long2 As Long, Optional ByVal Long3 As Long) As Variant
   If IsMissing(Long3) Then DoSomething = CLng(Long1 + Long2) Else DoSomething = CDbl((Long3 - Long2) / Long1)
End Function

[Niya]

Hmm, glad to hear that. It's just that the naming is so ugly.

This is normal for compilers. You should take a look at how C++ compilers mangles class method names, now that is ugly. What's important is that the user writing the code doesn't see these things.

Also, I see that optional parameters were mentioned in this thread. Don't yield to the temptation to use optional parameters as a way to mimic overloading. There certain overload scenarios that optional parameters cannot mimic. Eg:-

Sub DoSomething(p As String) 

Sub DoSomething(p As Integer)

[Zvoni]

This is normal for compilers. You should take a look at how C++ compilers mangles class method names, now that is ugly. What's important is that the user writing the code doesn't see these things.

Also, I see that optional parameters were mentioned in this thread. Don't yield to the temptation to use optional parameters as a way to mimic overloading. There certain overload scenarios that optional parameters cannot mimic. Eg:-

Sub DoSomething(p As String) 

Sub DoSomething(p As Integer)

Exactly what i was talking about (Polymorphism).
In this example the vb6-analogy would be

Sub DoSomething(p As Variant)
   If TypeOf(p)=vbString
       DoThis
   ElseIf TypeOf(p)=vbInteger Then
       DoSomethingElse
   End If
End Sub

IMO, that's the worst case scenario.
It feels to me, like
If the Parameter is a car, hitting "accelerate" would increase speed, while if the Parameter is a Bike, "accelerate" would cause a full brake including drifting around a corner....

EDIT:
And to put some "spice" into the Mix:
Let's introduce "generics"

Generic Sub DoSomething<T>(p As T)

End Sub

[Niya]

Exactly what i was talking about (Polymorphism).
In this example the vb6-analogy would be

Sub DoSomething(p As Variant)
   If TypeOf(p)=vbString
       DoThis
   ElseIf TypeOf(p)=vbInteger Then
       DoSomethingElse
   End If
End Sub

This would absolutely murder the performance of the translated code. It's better to go with DoSomething1, DoSomething2 etc as he originally intended. It is the best way to convert overloaded methods. Remember he is writing a transpiler, the conversion would be automated. The correct overload to call would be resolved by the transpiler itself at compile time.

[Zvoni]

This would absolutely murder the performance of the translated code. It's better to go with DoSomething1, DoSomething2 etc as he originally intended. It is the best way to convert overloaded methods. Remember he is writing a transpiler, the conversion would be automated. The correct overload to call would be resolved by the transpiler itself at compile time.

Yeah, i know, but i still say: it depends, what the original code (the code to be transpiled) is actually doing, because if it's really just emulating Optional Parameters, it would create redundant code

EDIT: .... or not
Just thought about it in terms of my own example above

Function DoSomething(ByVal name As String) As SomeType
   DoSomething=DoSomething6(Name, blablablabl)
End Function

Function DoSomething6(ByVal name As String, ByVal SomeOtherParameters As Something) As SomeType

End Function

He would actually avoid "Select/Case-ing" / "If/ElseIf-ing" all the optional Parameters

[SearchingDataOnly]

Maybe I can do this:

'--- Main Function ---

Function GetProperty(ByVal name As String, ParamArray args() As Variant)

'--- Aux Functions (Overloading Functions) ---

Function GetProperty__1(ByVal name As String, ByVal returnType As Type, ByVal types() As Type, ByVal modifiers() As ParameterModifier) As PropertyInfo

Function GetProperty__2(ByVal name As String, ByVal returnType As Type, ByVal types() As Type) As PropertyInfo

Function GetProperty__3(ByVal name As String, ByVal types() As Type) As PropertyInfo

Function GetProperty__4(ByVal name As String, ByVal returnType As Type) As PropertyInfo

Function GetProperty__5(ByVal name As String) As PropertyInfo

Function GetProperty__6(ByVal name As String, ByVal bindingAttr As BindingFlags) As PropertyInfo

Function GetProperty__7(ByVal name As String, ByVal bindingAttr As BindingFlags, ByVal binder As Binder, ByVal returnType As Type, ByVal types() As Type, ByVal modifiers() As ParameterModifier) As PropertyInfo

[techgnome]

Yeah, I thought along the same lines ... the "fun" part will be determining which secondary method/function to call based on what's in args ... I didn't put much thought into it beyond that though. Although, looking at it... you can figure out 4 of them based on the number of parameters alone... after that, there's three that each take three params... would need to look at the types at that point.

-tg

[Zvoni]

Yeah, I thought along the same lines ... the "fun" part will be determining which secondary method/function to call based on what's in args ... I didn't put much thought into it beyond that though. Although, looking at it... you can figure out 4 of them based on the number of parameters alone... after that, there's three that each take three params... would need to look at the types at that point.

-tg

Don't forget the Order of the ParamTypes.
Count and Types can be the same for two Overloads, just Order is different

If first String And second Long and third Double Then NukeMoscow
ElseIf First String And Second Double And third Long Then FeedDog

[SearchingDataOnly]

Yeah, I thought along the same lines ... the "fun" part will be determining which secondary method/function to call based on what's in args ... I didn't put much thought into it beyond that though. Although, looking at it... you can figure out 4 of them based on the number of parameters alone... after that, there's three that each take three params... would need to look at the types at that point.

-tg

Don't forget the Order of the ParamTypes.
Count and Types can be the same for two Overloads, just Order is different

If first String And second Long and third Double Then NukeMoscow
ElseIf First String And Second Double And third Long Then FeedDog

Maybe I can automatically generate the code for the main function GetProperty based on the function definitions of the aux functions GetProperty1...GetProperty7.

[Niya]

Typically compilers resolve which function to call by their signature. A function signature consists of the order and type of each parameter. The signature is combined with the name of the function to create a unique name. This is called name mangling and this is how compilers like the C++ compiler resolves overloading.

Let's do an example:-

        public int Foo(int a, int b) => a+b;
        public int Foo(int a, int b, int c) =>a+b+c;
        public float Foo(float a, float b) => a+b;
        public void Foo(string a) => Debug.WriteLine(a);
        public void Foo(TextBox a) => Debug.WriteLine(a.Text);

The above are different overloads of the function Foo. Now based on what I know about C++ name mangling if I were doing this, I'd start by building a table that matches a type to a number. Let's build a table from based all the types used in the above set of functions:-

int - 10
float - 11
string - 12
TextBox - 23

Each type is assigned a unique number and this number will be used to build the function signature. This signature will then be combined with the function name to produce a mangled name. In the case of your transpiler, this is what could come out:-

Public Function Foo_10_10(ByVal a As Long, ByVal b As Long) As Long
     Foo_10_10 = a + b
End Function

Public Function Foo_10_10_10(ByVal a As Long, ByVal b As Long, ByVal c As Long) As Long
    Foo_10_10_10 = a + b + c
End Function

Public Function Foo_11_11(ByVal a As Single, ByVal b As Single) As Single
    Foo_11_11 = a + b
End Function

Public Sub Foo_12(ByVal a As String)
    Debug.Print a
End Sub

Public Sub Foo_23(ByVal a As TextBox)
    Debug.Print a.Text
End Sub

So it now becomes easy to resolve which overload to call. The mangled name is created by suffixing it with type numbers of each parameter in the order in which they were defined. Let's say you had this call:-

var x = Foo(12.0f, 7.0f);

You use the name of the function at the callsite and the arguments to create the mangled name. Foo is called with a float as the first argument and a float as the second argument. In the table we built, a float is assigned the number 11 so combining that with the function name we get the mangled name Foo_11_11. That is name of the function the transpiler will embed at the callsite. The overload has been correctly resolved.

If your transpiler ever creates two identical mangled names for different functions, it should halt with an error. No two overloads can have identical signatures.

[SearchingDataOnly]

Nice solution.

In fact, my transpiler renames these overloaded functions internally, for example:

GetProperty___Name_ReturnType_Types_Modifiers
GetProperty___Name_ReturnType_Types
GetProperty___Name_Types
GetProperty___Name_ReturnType
GetProperty___Name
GetProperty___Name_BindingAttr
GetProperty___Name_BindingAttr_Binder_ReturnType_Types_Modifiers

But I decided to take your suggestion to do "signature recognition" of overloaded functions by their parameter types, thank you, Niya.

[Zvoni]

Nice solution.

In fact, my transpiler renames these overloaded functions internally, for example:

GetProperty___Name_ReturnType_Types_Modifiers
GetProperty___Name_ReturnType_Types
GetProperty___Name_Types
GetProperty___Name_ReturnType
GetProperty___Name
GetProperty___Name_BindingAttr
GetProperty___Name_BindingAttr_Binder_ReturnType_Types_Modifiers

But I decided to take your suggestion to do "signature recognition" of overloaded functions by their parameter types, thank you, Niya.

That would be the correct way.
AFAIK, when determining WHICH overload to call the Return Type (if even existent --> Sub instead of Func) is ignored!
(But it might differ from language to language)

[Niya]

While there is, strictly speaking, nothing wrong with involving return types in the process of resolving overloads, it should be noted that generally speaking, overloaded functions must differ by at least the number of parameters or the order of the types of the parameters. They cannot differ only by return type. For example, C# cannot resolve this:-

        public float Foo(int a, int b) => a+b;
        public int Foo(int a, int b) => a+b;

The above would not compile because they differ only by their return types. So if one is to include the return type of a method as part of the signature, it might also be a good idea to check for this. Though it would be interesting to see a language that could resolve such overloads, I can't say for sure if that is actually a good idea.

[Zvoni]

Niya,
i don‘t know C#, but in vb6 we always had the possibility to call a function as if it‘s a sub (and thusly ignoring the return type).
I‘d hazard a guess that‘s the reason, because a compiler wouldn‘t know which of those two functions to call, since both would have the same signature as a sub

[OptionBase1]

While there is, strictly speaking, nothing wrong with involving return types in the process of resolving overloads, it should be noted that generally speaking, overloaded functions must differ by at least the number of parameters or the order of the types of the parameters. They cannot differ only by return type. For example, C# cannot resolve this:-

        public float Foo(int a, int b) => a+b;
        public int Foo(int a, int b) => a+b;

The above would not compile because they differ only by their return types. So if one is to include the return type of a method as part of the signature, it might also be a good idea to check for this. Though it would be interesting to see a language that could resolve such overloads, I can't say for sure if that is actually a good idea.

Indeed, but imagine a scenario where those two functions exist solely, and imagine that those two functions do vastly different things. If this happens:

double d = Foo(1, 2)

then which one should be called? Both an int and a float can be "upgraded" to a double. Do you work "downstream" through the hierarchy of return variable types to see which is "closest" and call that one? It gets muddy fast. But it makes for interesting pondering.

[Niya]

Niya,
i don‘t know C#, but in vb6 we always had the possibility to call a function as if it‘s a sub (and thusly ignoring the return type).
I‘d hazard a guess that‘s the reason, because a compiler wouldn‘t know which of those two functions to call, since both would have the same signature as a sub

You mean the reason overloads can't be differentiated by their return types alone? If that is what you mean, the reason is actually for situations like this:-

object x = Foo(12.0f, 7.0f);

In the above code the return value of Foo is being assigned to variable x of type object. Situations like this are exactly why languages like C# require overloaded functions to differ by more than their return type. object can store anything, like a Variant in VB6. If overloading allowed functions to differ only by return type then the compiler would have to guess which type you intended to return for such functions. In other words, to support this kind of overloading, your language cannot not have types like Variant, Object etc that could hold any type. The compiler could then use the type of the variable or parameter that will receive the function's return value to resolve which overload to call because it will never be ambiguous.

[techgnome]

Indeed, but imagine a scenario where those two functions exist solely, and imagine that those two functions do vastly different things. If this happens:

double d = Foo(1, 2)

then which one should be called? Both an int and a float can be "upgraded" to a double. Do you work "downstream" through the hierarchy of return variable types to see which is "closest" and call that one? It gets muddy fast. But it makes for interesting pondering.

Neither would be called ... it wouldn't compile... regardless of what the output is, it's the parameters that matter which get called.
If the definitions were as such:

    public float Foo(float a, float b) => a+b;
    public int Foo(int a, int b) => a+b;

and you called it like this:
double d = Foo(1, 2)

Then the second one with the ints would be called. The parameters are integers, so that's the signature that matches, that's the one that gets called.

If you want the first to be called, then you need ot pass it floats.
double d = Foo(1.00, 2.00)

-tg

[OptionBase1]

Neither would be called ... it wouldn't compile... regardless of what the output is, it's the parameters that matter which get called.

If you read the post I was replying to, you would see that Niya posted a "what if a language allowed overloading simply by return type", and my post was in response to that idea.

[Niya]

Indeed, but imagine a scenario where those two functions exist solely, and imagine that those two functions do vastly different things. If this happens:

double d = Foo(1, 2)

then which one should be called? Both an int and a float can be "upgraded" to a double. Do you work "downstream" through the hierarchy of return variable types to see which is "closest" and call that one? It gets muddy fast. But it makes for interesting pondering.

This is also a very good point. I didn't even think of this one. So it seems it's problematic even without involving types like object.

[OptionBase1]

You mean the reason overloads can't be differentiated by their return types alone? If that is what you mean, the reason is actually for situations like this:-

object x = Foo(12.0f, 7.0f);

"A float's a float...but an object could be anything...it could even be a float!"

[Zvoni]

We might be all right, and we might be all wrong.
My point is, that you can overload subs, too, which don't have a return type, and that you can call functions as if they were a sub.

Bottom line from me: Compiling/evaluating/determining which overoaded function to call, the return type is completely ignored.
It doesn't even rate a "check"

Public Function Foo(ByVal Long1 As Long, ByVal Long2 As Long) As Long
  Foo = Long1 + Long2
End Function

Public Sub Foo(ByVal Long1 As Long, ByVal Long2 As Long)
   WriteToFile Long1, Long2
End Sub

'Somewhere Else
Public Sub Main()
   Call Foo(10,42)  'Which of the above is called?
End Sub

[Niya]

My point is, that you can overload subs, too, which don't have a return type, and that you can call functions as if they were a sub.

Yea, I get what you're trying to say. I sometimes forget that the BASIC language enforces a lot of bad habits and thought patterns. BASIC encourages programmers to think that there is some big difference between subs and functions when it fact they are actually the same thing. A sub is just a function where the return value is discarded. By convention most functions throw their return value in the EAX register. All you need to turn a typical function into a sub in the VB6 sense is to not do anything with whatever is in the EAX register after the function is called.

For example lets take this assembly:-

push ebp
mov ebp, esp

mov eax, [ebp + 8]
add eax, [ebp + 12]

mov esp, ebp
pop ebp
ret 8

The above could be "shelled" in a VB6 like this:-

Public Function Add(ByVal a As Long, ByVal b As Long) As Long

or like this:-

Public Sub Add(ByVal a As Long, ByVal b As Long)

Both are 100% valid because the truth is that there is no real difference between a sub and a function. All Sub does it tell the compiler you don't want to do anything with the return value which in this case resides in the EAX register. When you consider it this way, it becomes very clear why you cannot differentiate an overloaded function only by it's return type. It's because the return type of a function does not in any way change the fundamental behavior of the function.

All of this is to say that whenever you're thinking about compilers, transpilers, assemblers etc, as programmers that are practiced in BASIC, it really helps free ourselves of thinking in terms of subs and functions being distinctive because they are not really distinct.