PDA

View Full Version : Ambiguous Function Clarification needed



Chris Spencer
22-Nov-2021, 03:41 PM
From the help re ambiguous functions

https://docs.dataaccess.com/dataflexhelp/#t=mergedProjects%2FLanguageGuide%2FDeclaring_Func tion_Methods.htm

I need clarification on the compiler warnings for these functions as illustrated.

I am assuming this is allowed but it up to me as the developer to ensure that these methods are called with the GET syntax, correct?

If this is the case and they are definitely not called with the expression evaluation method these are safe to be left as they are?

Nothing actually spells this out that I can find

Vincent Oorsprong
23-Nov-2021, 03:55 AM
Chris,

In the past you did not get a warning and it was fully up to you to do it right. Following the "rule" that class members should be called with GET and global / built-in functions via expressions you never ran into the "problem".

If you write the following code


Object oTest is a cObject
Function Foo Returns Integer
Function_Return 1
End_Function
End_Object

Object oTest2 is a cObject
Function Foo Returns Integer[]
Integer[] iValues
Function_Return iValues
End_Function
End_Object

Procedure TestIt Global
Integer[] iResults

Move (Foo (oTest2)) to iResults
End_Procedure

Send TestIt

You will get two warnings. One on the declaration and one on usage.
When you change the code to:


CompilerLevelWarning AmbiguousFunctions Off
Object oTest is a cObject
Function Foo Returns Integer
Function_Return 1
End_Function
End_Object

Object oTest2 is a cObject
Function Foo Returns Integer[]
Integer[] iValues
Function_Return iValues
End_Function
End_Object
CompilerLevelWarning AmbiguousFunctions On

Procedure TestIt Global
Integer[] iResults

Move (Foo (oTest2)) to iResults
End_Procedure

Send TestIt


You only get one warning; on the usage
If you change the code to:


CompilerLevelWarning AmbiguousFunctions Off
Object oTest is a cObject
Function Foo Returns Integer
Function_Return 1
End_Function
End_Object

Object oTest2 is a cObject
Function Foo Returns Integer[]
Integer[] iValues
Function_Return iValues
End_Function
End_Object
CompilerLevelWarning AmbiguousFunctions On

Procedure TestIt Global
Integer[] iResults

Get Foo of oTest2 to iResults
End_Procedure

Send TestIt

you won't get any warnings and the code is OK as well. But watch out; when you change the code to:


CompilerLevelWarning AmbiguousFunctions Off
Object oTest is a cObject
Function Foo Returns Integer
Function_Return 1
End_Function
End_Object

Object oTest2 is a cObject
Function Foo Returns Integer[]
Integer[] iValues
Function_Return iValues
End_Function
End_Object
CompilerLevelWarning AmbiguousFunctions On

Procedure TestIt Global
Integer[] iResults

Get Foo of oTest to iResults
End_Procedure

Send TestIt

You will not get a warning but an error (illegial datatype conversion) at runtime.

So what is good and what is bad?

Chris Spencer
23-Nov-2021, 07:15 AM
Vincent

I am sorry but that didn't really answer my question.

I understand what the warnings are telling me.

All I won't to clarify is defining function with different returns types is allowable and acceptable, it is just up to me to ensure that I do not call them using the expression evaluation method.

Stephen W. Meeley
23-Nov-2021, 08:18 AM
Chris,

Allowable, yes, because if it wasn't we'd have made it an error (something we strongly considered).

Acceptable, not really, hence the warning. Bottom line is that its best not to do it at all.

Chris Spencer
23-Nov-2021, 02:03 PM
So what is the recommendation of the issue with importing a com library like chilkat which has numerous functions in different classes that return different types for the same named function.

Surely not go into the code and rename everyone of them to something different.

This is what raise the question, probably should have mentioned that upfront

Stephen W. Meeley
23-Nov-2021, 02:33 PM
Chris,

Talk about burying the lead :cool:

Yes, the fact that OPC (Other People's Code) can be out of your control is one of the main reasons why we didn't go with full-on error conditions. Change what you have control over, understand, and live with, any consequences of what you don't.

raveens
23-Nov-2021, 06:07 PM
Hi Vincent

Just to be clear...

if I use the recommended "GET" method to access functions, then the returned datatype is always safe/correct as its based on the object.

BUT, if I use the expression evaluator with a "MOVE" then the returned datatype could be wrong as it uses the first defined function's returned datatype.

Can you please confirm this ?

As with Chris, we use Chilkat too and found the same issue - same function names across multiple mixins but with different returned datatypes.


Thanks

wila
23-Nov-2021, 07:24 PM
Chris,

Talk about burying the lead :cool:

Yes, the fact that OPC (Other People's Code) can be out of your control is one of the main reasons why we didn't go with full-on error conditions. Change what you have control over, understand, and live with, any consequences of what you don't.

SWM,

No offence, but this is a bug.
You can declare it as "WONT FIX" and document it however you like, but it stays a bug.

Oh.. and your code is OPC from my point of view too :D
--
Wil

wila
23-Nov-2021, 09:14 PM
Yes, the fact that OPC (Other People's Code) can be out of your control is one of the main reasons why we didn't go with full-on error conditions. Change what you have control over, understand, and live with, any consequences of what you don't.

Sorry for rattling your cage, but I just realized that it is highly debatable that this even is an OPC matter.
The code is generated by DAWs wizards...
--
Wil

Vincent Oorsprong
24-Nov-2021, 03:38 AM
Raveen,

The GET syntax works good unless you made a programming error.

The expression syntax may result in an error when the datatypes cannot convert automatically or are incompatible.

PS: I always followed the "rule" that class members should be addressed with GET and global or built-in functions with expressions.

Vincent Oorsprong
24-Nov-2021, 03:47 AM
Wil,

While you are right that the wizards create the code it would be almost impossible to create a different unique name. You would need to scan CDS to see if a name already exists and then create a different name which does not match with documentation. And when you later attach to an external library you still can get the warnings.

If you stick with the "rule" that class members should use GET and global / built-in functions with an expression syntax you can "simply" ignore/disable the ambigious function warnings.

Maybe we should go back the limitation from DataFlex 6 or 7 where you could only define a function once, so names had to be unique, system wide :cool:

Chris Spencer
24-Nov-2021, 04:45 AM
I would hope the emoji suggests you are tongue in check.

otherwise definitely not!

wila
24-Nov-2021, 05:42 AM
Vincent,


Wil,

While you are right that the wizards create the code it would be almost impossible to create a different unique name. You would need to scan CDS to see if a name already exists and then create a different name which does not match with documentation.

I think you already point out here that that would not exactly be an improvement ;)

Not arguing that a developer should use the get syntax instead of the expression syntax.

Also I'm not arguing that the warning doesn't help, it does help. It makes developers aware of this issue which is a good thing.
Every little bit helps. But I will keep calling it an issue until it has been addressed.

You're free to call it anything else, but I'm pretty sure this question will keep on coming back over and over again.
--
Wil

starzen
24-Nov-2021, 06:37 AM
Agree

it is a serious design flaw in the language. It also means that you cannot call these functions using runtime expressions

it could be fixed by fixing the expression evaluator