Cobra Forums

Posted: **Thu Feb 05, 2009 2:15 am**

class Foo
    
    def main is shared
        x as IEnumerable<of int> = [1, 2, 3, 4]
        a = x.toArray

The compiler complains that toArray is not a member of IEnumerable<of int>, but it is listed as so (well, as an extension method actually) in the MSDN docs.

Posted: **Thu Feb 05, 2009 2:18 am**

I just noticed that this extension method was added in .NET 3.5, so that's probably the cause. I guess I'll have to use the obvious workaround which is to build the array myself.

Posted: **Thu Feb 05, 2009 4:09 am**

I found another issue, and I think this is more likely to be caused by a bug.

Consider:

extend String
    def split(chars as char*) as List<of String>
                 return ['dummy']
                        
class Foo            
    def main is shared
        print 'a:b'.split(@[c':'])       # Prints ['dummy'] <!-- s:( --><img src="{SMILIES_PATH}/icon_e_sad.gif" alt=":(" title="Sad" /><!-- s:( -->

When the main method is executed, it seems like the compiler is generating a call to my split(char*) extension method. This is shocking, because there is also a split(char[]) method in String that matches exactly the argument I'm passing.

I've tried to reproduce the problem with a class of my own:

class Foo
    def bar(x as int[])
        pass
extend Foo
    def bar(x as int*)
        .bar(List<of int>(x).toArray)
class Baz
    def main is shared
        Foo().bar(@[1, 2])

However, this seems to works perfectly (i.e., the compiler correctly generates a call to bar(int[]).

To the best of my knowledge there is no easy workaround for this, other than giving my extension method a different name (e.g., split2), but that is not very satisfying.

Posted: **Thu Feb 05, 2009 8:14 pm**

I confirm. I don't know the source of the problem at this point. Can you add a ticket?

Posted: **Fri Feb 06, 2009 1:10 am**

Chuck wrote:I confirm. I don't know the source of the problem at this point. Can you add a ticket?

Done. I have boldly assigned the ticked to myself, because I want to give it a try if you don't mind. I will try to write an equivalent example directly en C#, confirm that it works (otherwise it's a bug in C# itself, which doesn't seem likely), and see what's different in the code generated by Cobra.

Posted: **Fri Feb 06, 2009 8:45 am**

Go for it. Let me know if you get stuck on anything or have any questions.

Posted: **Sat Feb 07, 2009 4:29 am**

The following IEnumerable methods:

http://msdn.microsoft.com/en-us/library/19e6zeyy.aspx

seem to be exclusive of the 3.5 framework. Since Cobra targets v2.0, we cannot make use of them which is a pity as some of them are really handy. So I thought that it might be a nice idea to implement them as pure Cobra extension methods. As an added benefit, this way they'd be available in all backends. We could even add other enumerator related methods, such as "enumerate" or "zip", that are not on .NET but which we can borrow from other languages like Python. This way Cobra would have it's own "itertools" module.

Chuck, what do you think about this? I could take care of it, I already implemented toArray, so we're half way there

extend IEnumerable<of T>
      def toArray as T[]
           return List<of T>(this).toArray

Posted: **Sat Feb 07, 2009 5:22 am**

Yeah, I'm good with that.

Cobra Forums

is this a bug?

is this a bug?

Re: is this a bug?

Re: is this a bug?

Re: is this a bug?

Re: is this a bug?

Re: is this a bug?

Re: is this a bug?

Re: is this a bug?