Is Operator_Convert a catch-22 case?

Say I have a class named myClass (how clever!) with the following Operator_Convert

Operator_convert( value as Pair )

If I try to pass a Variant containing a Pair object, I get an IllegalCastException at runtime (Xojo 2019r1, macOS 10.14.4). So I have added another Operator_Convert:

Operator_convert( value as Variant )

but now, If I try to pass a Pair (not in a Variant), the compiler complains “There is more than one item with this name and it’s not clear to which this refers.”

So I removed the first Operator_Convert( value as Pair ) and, strangely, it works if I pass a Pair but not if I pass a Pair inside a Variant (IllegalCastException: Pair cannot be cast to myClass) even if the method expects a Variant.

I am forgetting something?

[quote=439410:@StphaneMons]
I am forgetting something?[/quote]
that variants are evil ?

this is curious in some ways since if you overload a method like

Public Sub foo(v as variant)
End Sub

Public Sub foo(i as integer) 
End Sub

and call it with

Dim i As Integer
Dim v As Variant

foo(i)
foo(v)

theres no issue and the right one is called

but thats not happening with operator_convert

There may be some reason that escapes me but I cannot think of why this difference would exist for an overload vs opertaor_convert when there is an exact match

[quote=439410:@StphaneMons]So I removed the first Operator_Convert( value as Pair ) and, strangely, it works if I pass a Pair but not if I pass a Pair inside a Variant (IllegalCastException: Pair cannot be cast to myClass) even if the method expects a Variant.

I am forgetting something?[/quote]

A variant is the only way in lots of cases, it just act as a container to send any value to the method, then you can use Introspection.GetType to use the correct type instead of overloading (not the best practice, but that is the xojo way)

The idea is that you set up the variant parameter, and then just send it ANY other data type, no need to put the data inside a variant and send that. But, if you have already a variant, you can allways cast it to a pair first:

[code]Dim x As Class1

Dim p As New Pair (1, 2)
Dim v As Variant = p

'This works
x = p

'This fails with an IlegalCastException: Pair cannot be cast to Class1
x = v

'This works by casting the variant to a pair first, just for xojo to put in a variat again. lol
x = Pair (v)[/code]

It really looks like a bug, the compiler wanting to cast the variant to a class instead of just passing it as is.

@Ivan Tellez — Well x = Pair( v ) works only for a regular method, but not with Operator_Convert.

It does work if there is only one Operator_Convert expecting a variant.

I just tend to avoid variants where ever I can

@Ivan Tellez —

Yes but strangely you then cannot pass a Pair as a Variant even though there is only one Operator_Convert and it expects a Variant.

Oh by the way, part of this bug has been reported 6 years ago! Yet it is still not ranked in the bug-to-fix list!!

[quote=439660:@StphaneMons]@IvanTellez
Yes but strangely you then cannot pass a Pair as a Variant even though there is only one Operator_Convert and it expects a Variant.[/quote]

That is why i said:

do you have te case number?

@Ivan Tellez — The case number is 28146 (I don’t even know how to paste a link to that case)

From Feedback app: Click on Report Actions: Copy Link and directly paste into the forum without changing anything:

<[https://xojo.com/issue/28146](https://xojo.com/issue/28146)>

will auto convert to: <https://xojo.com/issue/28146>

Uh… there is no public facing bugs to fix list in Feedback. We do however have a User Favorites list, but its simply that… a list of cases that users have indicated are important to them. We use this list when planning our development cycles as one of many factors we consider, but it is certainly not used as a to fix list.

@Greg O’Lone — Oh OK, thanks for the clarification