odd failure in test block

[khjklujn]

I think this one might be more of a C# thing than something with cobra, but it's too subtle for my C# skills, so I'm hoping somebody else can explain it to me.

The following code fails to compile on both windows and mono:

interface IVAlign
    get value as dynamic?

class VAlign
    implements IVAlign
    shared
        get top as IVAlign
            return VAlign('top')

    var _value as dynamic?

    get value from var

    def init(value as String)
        _value = value

class Bob
    var _vAlign as IVAlign?

    pro vAlign from var

    test
        t = Bob()
        t.vAlign = VAlign.top
        assert t.vAlign.value == 'top'

class Program
    shared
        def main
            t = Bob()
            t.vAlign = VAlign.top
            assert t.vAlign.value == 'top'

Specifically, it doesn't like the static method that is being generated for the test. Remove the test block, and it's happy. Alternatively, use VAlign as the types for VAlign.top and _vAlign instead of IVAlign, and it's happy. Finally, rename vAlign to anything else, and it's happy.

Not that this is something that's too terribly difficult to work around, but I do find it puzzling.

[Charles]

This is kind of a C# thing, but it's addressable.

So the offending C# generated code is:

Code: Select all

      t.VAlign=(VAlign.Top);


And the problem is that when C# sees "VAlign" on the right, it sees it as the property "this.VAlign" instead of the global type "VAlign". Recall that under the hood, Cobra capitalizes members to make your Cobra DLLs comfortably consumable by C# programmers.

I changed the code like so:

Code: Select all

      t.VAlign=(global::VAlign.Top);

And reissued the C# compilation command which I copied from the output of "cobra -v:2 ..." -- it works.

So I suppose Cobra must generate that "global::" whenever a stand-alone identifier or left hand component of "foo.bar" has the same name as a capped member. Or just put the global:: in always.

[Charles]

Fixed.

Btw you made a good point about how it works when changing the type of the var/property. I don't even know why that's the case.

I added in the qualification to the type and locked it down with a couple test cases (one where everything is in the global/unnamed namespace and another where everything is in an explicit namespace).

Thanks for the report.

[khjklujn]

Cool. Thanks. Saves me from having to refactor my tests.