Visual Basic and Ruby: Happy Together?
22. Aug, 2006 
4 Comments
Tim Ng, who works on the Visual Basic compiler team, has spent some time digging into RubyCLR and has some nice things to say about it. That post is really nice because he shows how to explicitly call Ruby methods from VB.
Tim is interested in a scenario that frankly I haven’t spent much time thinking about – and that is hosting Ruby inside of a Visual Basic (or any other .NET language for that matter). Most of the effort that I’ve put into making Ruby objects callable from CLR objects has been focused on data binding scenarios, but Tim wants more 
Most of his requests on that list are very reasonable. The only real problem is making all methods of a Ruby object available to be called from VB. The challenge there is that you can add methods to a Ruby object or class at any time. I create the moral equivalent of a Runtime Callable Wrapper class, but like any other .NET class, it’s static. Now I don’t really know how RCWs are really implemented, so if someone can help me understand how to build a CLR object that does the equivalent of method_missing in Ruby, that will help me get this feature out the door faster.
Hey, interesting stuff, I’ve written up my own experiences with RubyCLR, specifically using Ruby and C# together, at http://www.crazycool.co.uk/blog/2006/08/22/RubySharp.
I too would like to see some of the more complex bridging features appear in RubyCLR, and would be happy to contribute code or testing if you’d like the help
Keep up the great work!
Cheers,
-= El =-
Hi John,
I’ve always been curious about the IExpando interface (but never found a use for it). Might this be useful here?
From the documentation at:
http://msdn2.microsoft.com/en-us/library/8023ct8s.aspx
—
IDispatchEx
If the class implements IDispatchEx, the RCW implements IExpando. The IDispatchEx interface is an extension of the IDispatch interface that, unlike IDispatch, enables enumeration, addition, deletion, and case-sensitive calling of members.
—
I’ve quite possibly got the wrong end of the stick.
Thanks, Jamie.
Hi El,
Thanks for putting together that post! The problem with statically compiling the interop code is the fact that the Ruby code can change at any time – it’s not necessarily bound to a source file as in your example – someone at runtime can change the behavior of an object. The highly dynamic nature of Ruby makes it difficult to do this kind of stuff (not impossible – just difficult) so I used the interfaces hack to “lock down” the behavior of a Ruby object.
-John
Hi Jamie,
This does look promising … I’ll have to do some experiments with IExpando and VB to see how they work together. But this looks like it just *might* do the trick, providing that VB uses it (and I see no reason why they wouldn’t).
Added to my list of things to do post-rewrite of reflection goo
Thanks!
-John