I have the following demo code. In Vulcan.NET, it compiles and runs as expected. The X# compiler gives the error
XS0121 The call is ambiguous between the following methods or properties: 'XS1715_XS.Log.Debug(string, params object[])' and 'XS1715_XS.Log.Debug(string, System.Exception, params object[])' XS1715_XS
PUBLIC STATIC CLASS Log
PUBLIC STATIC METHOD Debug(pcMessage AS STRING, [ParamArray] poArgs AS OBJECT[]) AS VOID
Console.WriteLine(STRING.Format(pcMessage, poArgs))
PUBLIC STATIC METHOD Debug(pcMessage AS STRING, poException AS Exception, [ParamArray] poArgs AS OBJECT[]) AS VOID
Console.WriteLine(STRING.Format(pcMessage, poArgs))
Console.WriteLine(poException)
END CLASS
FUNCTION Start() AS VOID
Console.WriteLine("Hello World!")
LOCAL uArgument := "Test" AS USUAL
Log.Debug("Log Message", uArgument)
Console.WriteLine("Press any key to continue...")
Console.ReadKey()
I see 2 things I think are troublesome:
[*]
[*]an usual is used, so the compiler can't see whether an exception is put into it or not.
[*]if you would specify it as an 'exception', both methods can be applicable, because the parameterlist is specified as object[] which can also accommodate an 'exception'
Because of the second point, I can understand the warning 'ambiguous method'.
You could use just one method (the first one), and first test whether the first argument is a 'exception' (sub)type and then decide what to do.
I agree that this is easy to solve by changing the code. But I don't want to change the code, because it is very very much code and it was working before (with Vulcan.NET) and now it doesn't (with X#).
So at least I want to check back whether this incompatibility is intentional.
The thing is that in many cases vulcan allowed some code to compile, but at runtime it would often behave differently to what you expect, or throw exceptions. In this sample, it seems this is not the case, but adjusting x# to have the same behavior with vulcan here, could lead to create potential problems elsewhere.
We will have a look, but in the meantime, are you using this code a lot? Can you type the uArgument LOCAL as OBJECT, instead of USUAL? Or is it possible to change the way it is being called to:
I cannot really estimate how often we use this code because I'm not yet able to compile everything, but since Usuals have been used in our code a lot, I fear that this affects us pretty heavily.
Kromi wrote:
I cannot really estimate how often we use this code because I'm not yet able to compile everything, but since Usuals have been used in our code a lot, I fear that this affects us pretty heavily.
Just to be clear, this is not a general vulcan-incompatibility with USUALs, it's only with this very specific case of using [ParamArray] in 2 separate overloaded methods and passing a USUAL to them. I think usually such a construct is very rare, do you indeed use this a lot in your code? Anyway, I will log this and will see if Robert can find a quick solution without harming anything else.
