Type 'x' already defines a member called 'y' with the same parameter types

[Chris]

Ah, thanks, I was not aware that it is possible to use is null in c#! Personally I don't like this, but if you'd like it implemented also in X#, can you please open a feature request in github?

[baramuse]

About the exception, you can get this only if you do a late bound call, since this is a runtime error. The code in your sample (that uses var) is strongly typed, so it can't produce that error. Maybe the actual code is a bit different? If not, can you please post a full compilable code sample that I can compile here to have a look?

If you indeed need to do late bound calls though, it's gonna be tough with such overloads and especially default values, it's getting too complicated. So I'd suggest to keep things simple in the method definitions, or just use only strongly typed calls of course.

You're right the actual code is not exaclty that so I'll test a bit more with all the execution chain and I'll come back to you !

You were right, here is the actual code :

Code: Select all

lOk := SetDataDict():MakeIndex( #LOCNOTES )

FUNCTION SetDataDict( oDataDict ) AS USUAL CLIPPER
    LOCAL  oPrevDict AS DataDict
    STATIC DataDict  AS DataDict              
    IF ! IsNil( oDataDict )
        oPrevDict := DataDict
        DataDict  := oDataDict
    ELSE
        oPrevDict := DataDict
    ENDIF
    RETURN oPrevDict

Because "SetDataDict" is using CLIPPER convention means it will make a late bound call ?
In that case my best approch would be, if I want to start strong typing, to create all the possible overloads in order to avoid late bound call exceptions until everything is strongly typed ?

[Chris]

Code: Select all

lOk := SetDataDict():MakeIndex( #LOCNOTES )

FUNCTION SetDataDict( oDataDict ) AS USUAL CLIPPER
    LOCAL  oPrevDict AS DataDict
    STATIC DataDict  AS DataDict              
    IF ! IsNil( oDataDict )
        oPrevDict := DataDict
        DataDict  := oDataDict
    ELSE
        oPrevDict := DataDict
    ENDIF
    RETURN oPrevDict

Because "SetDataDict" is using CLIPPER convention means it will make a late bound call ?
In that case my best approch would be, if I want to start strong typing, to create all the possible overloads in order to avoid late bound call exceptions until everything is strongly typed ?

Fortunately even CLIPPER methods/functions allow strongly typing the return type (not the parameters), so just set the return type to AS DataDict instead of AS USUAL and now the code will be strongly typed!

[baramuse]

Code: Select all

lOk := SetDataDict():MakeIndex( #LOCNOTES )

FUNCTION SetDataDict( oDataDict ) AS USUAL CLIPPER
    LOCAL  oPrevDict AS DataDict
    STATIC DataDict  AS DataDict              
    IF ! IsNil( oDataDict )
        oPrevDict := DataDict
        DataDict  := oDataDict
    ELSE
        oPrevDict := DataDict
    ENDIF
    RETURN oPrevDict

Because "SetDataDict" is using CLIPPER convention means it will make a late bound call ?
In that case my best approch would be, if I want to start strong typing, to create all the possible overloads in order to avoid late bound call exceptions until everything is strongly typed ?

Fortunately even CLIPPER methods/functions allow strongly typing the return type (not the parameters), so just set the return type to AS DataDict instead of AS USUAL and now the code will be strongly typed!

Yes I can strongly type that function but I couldn't foresee the crash before it happenned so that's not going to be acceptable as the codebase is too huge.
So having all the function overloads compiles AND works and does not crash at runtime, will be out options for us :

Code: Select all

	METHOD MakeIndex()  AS LOGIC STRICT
		RETURN SELF:MakeIndex({}, NULL)

	METHOD MakeIndex(symServer AS SYMBOL)  AS LOGIC STRICT
		RETURN SELF:MakeIndex({symServer}, NULL)

	METHOD MakeIndex( aServerListe := NULL AS ARRAY OF SYMBOL, cFileName := NULL AS STRING) AS LOGIC STRICT

Thanks for all your help !

[Chris]

You're welcome!

Just please note that late binding (by using the USUAL type) is a compatibility feature, for code that is inherited from VO and other dialects, which did not support method overloading, so things were much simpler in making this work. Since you are using method overloading, this is new code, so it's much better to avoid using the USUAL type at all in it.

[baramuse]

You're welcome!

Just please note that late binding (by using the USUAL type) is a compatibility feature, for code that is inherited from VO and other dialects, which did not support method overloading, so things were much simpler in making this work. Since you are using method overloading, this is new code, so it's much better to avoid using the USUAL type at all in it.

But that's the thing, it's not really new code, we just want to start strong typing the current code limiting at possible the side effects.
So in that case, if I want to strong type the DataDict class without having to worry about the rest of the code calling it, I need to provide the new overloads for legacy late bounding code to still work without crashing at runtime

[robert]

Basile,

Adding support for the IS NULL pattern and IS NOT NULL pattern is on our todo list.



Robert


I have added a Github issue for this now:
https://github.com/X-Sharp/XSharpPublic/issues/1422

[Chris]

Basile,

You're welcome!

Just please note that late binding (by using the USUAL type) is a compatibility feature, for code that is inherited from VO and other dialects, which did not support method overloading, so things were much simpler in making this work. Since you are using method overloading, this is new code, so it's much better to avoid using the USUAL type at all in it.

But that's the thing, it's not really new code, we just want to start strong typing the current code limiting at possible the side effects.
So in that case, if I want to strong type the DataDict class without having to worry about the rest of the code calling it, I need to provide the new overloads for legacy late bounding code to still work without crashing at runtime

OK, I understand. That's the main problem with late bound calls, the compiler has no way to check them, so a possible error can only happen at runtime. I will open a bug report for the runtime crash when trying to add this particular case of overloaded methods, but I am afraid it will be too difficult to make sure that ALL possible combinations of parameters in overloads will be handled correctly. And even if they do in this case, there still might be a slightly different variation somewhere else in your program that will still fail (And again this can be only found by testing at runtime).

Still, you can choose a middle path, instead of providing many new overloads, you could strong type the previously existing single one. Even you will have to type some parameters AS USUAL, it's still better than have that, than a CLIPPER calling convention method. With the strongly typed version with USUALs (and when the method is called through a strongly typed var, not through a USUAL), the compiler may not be able to type check the parameters (the USUAL ones), but at least it can check the amount of them, the return type, even the name of the method to make sure it's spelled correctly. Plus execution will be a little faster...