Is Operator_Convert a catch-22 case?

  1. 3 months ago

    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?

  2. Norman P

    Jun 1 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    @Stéphane ;Mons I am forgetting something?

    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

  3. Ivan T

    Jun 1 Pre-Release Testers
    Edited 3 months ago

    @Stéphane ;Mons 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?

    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:

    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)

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

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

  5. Ivan T

    Jun 1 Pre-Release Testers

    @Stéphane ;Mons @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.

  6. Norman P

    Jun 1 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    I just tend to avoid variants where ever I can

  7. @Ivan T

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

    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.

  8. 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!!

  9. Ivan T

    Jun 3 Pre-Release Testers

    @Stéphane ;Mons @Ivan T
    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.

    That is why i said:

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

    do you have te case number?

    @Stéphane ;Mons 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!!

  10. @Ivan T — The case number is 28146 (I don't even know how to paste a link to that case)

  11. Alberto D

    Jun 3 Pre-Release Testers

    @Stéphane ;Mons @Ivan T — 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:

    <feedback://showreport?report_id=28146>

    will auto convert to: Feedback Case #28146

  12. Greg O

    Jun 4 Xojo Inc

    @Stéphane ;Mons 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!!

    Uh... there is no public facing “bugs to fix” list in Feedback. We do however have a User Favorites list, but it’s 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.

  13. @Greg OLone — Oh OK, thanks for the clarification

or Sign Up to reply!