As I was implementing my dynamic help feature, I was constantly annoyed by the code that I had to write to manipulate CLR arrays. That code looked something like this:

array = get_an_array_from_somewhere
holder_for_a_bunch_of_things = []
0.upto(array.length - 1) do |i|
# gather up a bunch of things
end
# use holder_for_a_bunch_of_things

Now, most Ruby programmers would rather use the collect method from the Enumerable module:

array = get_an_array_from_somewhere
holder = array.collect do |item|
# expression for transforming an item
end

I’m happy to say that RubyCLR now automatically mixes in the Enumerable module for any CLR type that implements the IEnumerable interface. This means that your Ruby programs will feel much more like a Ruby program.

RubyCLR now also automatically defines the <=> method for any object that implements the IComparable interface. It prefers IComparable<T>, but will bind as well to IComparable. This means that you can now use the Enumerable#sort method to sort a .NET array, or list (if that’s what you want to do).

Here’s a simple unit test that validates this behavior:

def test_object_sort
john  = Person.new('John')
steve = Person.new('Steve')
mike  = Person.new('Mike')
a = ArrayList.new
a.add(john)
a.add(steve)
a.add(mike)
b = a.sort
assert_equal Array, b.class
assert_equal 'John', b[0].name
assert_equal 'Mike', b[1].name
assert_equal 'Steve', b[2].name
end

The Person object implements the IComparable interface. Notice as well that the Enumerable#sort method returns a Ruby array, not a CLR array.

I have a lot more ideas about how to further blur the boundary between Ruby and the CLR (such as letting Ruby objects implement arbitrary CLR interfaces), but those features will have to wait for a while.

I’m now in app-writing mode for the next release. There will be a really nice Avalon aka Windows Presentation Foundation sample app, so make sure you go and download the February WinFX CTP now!