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”.