1 Attachment(s)
2 functions, same name, different parameters - what goes wrong here?
What are we doing wrong here?
We noticed that DF has issues when 2 functions are defined with the same name, but with different parameters.
I tested this in 18.1, 19.0 and 19.1: it all goes wrong.
It's best explained by giving you a reproducable example in the Order Entry workspace.
Add this to Vendor.DD:
[CODE][FONT=Verdana]
// Parameter 1: integer, parameter 2: string
Function GetTestParameters Integer iParameterInteger String sParameterString Returns Integer
Showln iParameterInteger " " sParameterString
Function_Return 1
End_Function
[/FONT][/CODE]
This method has 2 parameters: an integer and a string.
Then add this to the OrderHea.DD:
[CODE][FONT=Verdana]
[LEFT][COLOR=#222222][FONT=Verdana]// Parameter 1: string, parameter 2: integer[/FONT][/COLOR][/LEFT]
Function GetTestParameters String sParameterString Integer iParameterInteger Returns Integer
Showln iParameterInteger " " sParameterString // Set Breakpoint here.
Function_Return 1
End_Function
Procedure DoTest
String sDummy
Move (GetTestParameters(Self, "TEST", 123)) to sDummy // This one goes wrong
Get GetTestParameters "TEST" 123 to sDummy // This one works
End_Procedure
[/FONT][/CODE]
This will add a function with the [B]same[/B] name, but with the parameters the other way round: First a string, then an integer.
Next add a button to Order.vw:
[CODE]
[FONT=Verdana]Object oTestBtn is a Button
Set Label to "Test"
Set Location to 156 81
Set peAnchors to anBottomLeft
Set psToolTip to "Send test to DDO"[/FONT]
[FONT=Verdana]
Procedure OnClick
Send DoTest of OrderHea_DD
End_Procedure // OnClick
End_Object // oPrintBtn
[/FONT][/CODE]
Set a breakpoint at the showln in [COLOR=#222222][FONT=Verdana]GetTestParameters in OrderHea.dd.
[/FONT][/COLOR][LEFT][COLOR=#222222][FONT=Verdana]Then c[/FONT][/COLOR]ompile and run.
[/LEFT]
Click the button.
It first starts:
[CODE]
[LEFT][COLOR=#222222][FONT=Verdana]Move (GetTestParameters(Self, "TEST", 123)) to sDummy[/FONT][/COLOR][/LEFT]
[/CODE]
It stops at the breakpoint. Now look at the local variables:
[ATTACH=CONFIG]13011[/ATTACH]
Eventhough the first paramater is a string test, the variable [LEFT][COLOR=#222222][FONT=Verdana]sParameterString is 0.
And the variable iParameterInteger contains a string "123".
What happens here is that the method uses the parameters of the [B]function that is defined in Vendor.DD[/B] instead of the one in OrderHea.DD, even though everything takes place in the OrderHea class.
The next line
[LEFT][COLOR=#222222][FONT=Verdana][CODE]Get GetTestParameters "TEST" 123 to sDummy[/CODE]
goes well though.
What are we doing wrong here?
We should be able to use methods with the same name but different parameters imho.
But somehow this goes wrong?
[/FONT][/COLOR][/LEFT]
[/FONT][/COLOR][/LEFT]
Re: 2 functions, same name, different parameters - what goes wrong here?
same thing happens if you declare two properties in 2 objects with the same name or 2 functions with in different classes with the same name but different return types
remember the renamed property in VPE we talked about? was the same issue with a function returning a number but there was a function declared with the same name returning an integer. And quietly DF changed all functions to return an integer
either it needs to throw an error or handle it properly. This can cause so many issues by for example adding another package you may not even have created or DAW adding a function somehwere with a name you already used etc
Re: 2 functions, same name, different parameters - what goes wrong here?
You should always Get methods of an object and Move global functions
If you Move an object method what you see can happen and it is just the way the expressions are evaluated since the year dot
Most of the time you 'get away with it' but sometimes, like in this case, you will get a result you don't expect
Re: 2 functions, same name, different parameters - what goes wrong here?
Yes, I remember you told me.
But we never had issues with this until we ran into a problem in 19.1: We got to see an error 54 because of this problem.
So we first thought it was an issue in 19.1, but it seems it has been an issue all along. (But we never saw the error 54 before).
Re: 2 functions, same name, different parameters - what goes wrong here?
its one of the many hidden dangers in the language. Luckily in your case it showed up as an error in our case it was silently modifying the return data loosing the decimals
Re: 2 functions, same name, different parameters - what goes wrong here?
Andrew,
Not good enough as it is allowed by the compiler and a bucket load of developers like to use move for functions.
The compiler should be throwing warnings if you do this.
Yes that would be very very noisy, but IMO Data Access only has two options on handling this properly.
1. Adding a warning if people use move and thus have potential problems in their codebase
2. Fix the problems
--
Wil
Re: 2 functions, same name, different parameters - what goes wrong here?
Hi Wil,
I agree.
We didn't know this and I don't know how we could have known this.
Re: 2 functions, same name, different parameters - what goes wrong here?
No it is [B]not[/B] one of the [B]hidden dangers[/B] in the language...
Since DataFlex 7 the language allows developers to create two or more functions with the same name. This was not possible till that version. We introduced a language guide book and AFAIK this describes the RULE that calling functions via expressions is reserved for built-in and global functions and class members should be called via GET.
Note that expression executes the right function but the return type causes the problem.
Re: 2 functions, same name, different parameters - what goes wrong here?
[QUOTE][COLOR=#333333]We didn't know this and I don't know how we could have known this.[/COLOR][/QUOTE]
AFAIK it is in the language guide and it is certainly documented in the Discovering DataFlex book.
Re: 2 functions, same name, different parameters - what goes wrong here?
[QUOTE=Vincent Oorsprong;347093]
Note that expression executes the right function but the return type causes the problem.[/QUOTE]
Hi Vincent,
The returntype isn't the problem here.
The parameters aren't filled correctly. It makes a string of an integer and an integer of a string.