This article dates back from 2010, you mentioned about some limitations:
” The most significant are calls to methods with out or ref parameters. You also won’t be able to inherit a Ruby class from a CLR class or implement a CLR interface since that requires us to emit a proper CLR type. ”

Are these still issues in the latest version of IronRuby for WP7?

Thank you!
Andrew

rb> #py
py> class c(object):
py|   def foo(self, a, b):
py|     print self, "a:", a, "b:", b
py|
py> #rb
rb> c.new.foo(1,2)
<c object at 0x000000000000002B> a: 1 b: 2
=> nil
rb>

In the example above, IronPython defines the class “c” (lower case c) on the current module. The variables of the module are exposed as variables of the corresponding DLR scope. The REPL shares the scope accross multiple executions. IronRuby accesses variables on it via method calls. In Ruby, “c.new.foo” are actually 3 methods calls – of methods “c”, “new” and “foo” in this order. There is no method “c” defined on top-level main singleton (nor on Object or Kernel module). Therefore “method_missing” defined by IronRuby on top-level main singleton is invoked. Its implementation looks into the DLR scope for variable “c” and finds the Python class.

Now if the Python class name starts with a capital letter we need to do “C().new.foo” or “self.C.new.foo” because “C.new.foo” in Ruby is a constant lookup “C” followed by methods calls to “new” and “foo”. Since we do “unmangle” names for .NET method calls (you can use both “create_engine” and “CreateEngine” to call C# method “CreateEngine”) we might as well do this for scope lookups in a future version of IronRuby. Then you could define “class MyClass(object)” and access it from Ruby as “my_class”.