It seems like we stirred up some controversy with these lines of code in our demo:
JS = require 'foo.js'
...
JS.initialize
Let's be clear about what this code does: it creates a ScriptModule (a DLR type) that represents the execution context of the foo.js code, and assigns it to the JS constant. The JS.initialize line calls the initialize method in foo.js. This is a user-defined method, and not some kind of DLR initialization thing.
We debated the idea of using require to import foreign modules in my office for a very short period of time before checking in the change. It seemed like a natural thing to do - monkey-patch the require method so that we can import foreign modules into IronRuby.
Nobody has argued that importing foreign modules into IronRuby is a bad idea.[1] Rather, I think that folks have taken issue with using require as the mechanism for doing so.
Point taken. We will have a different mechanism for doing so in the future.
But this brings up an important meta-level issue: our commitment to doing the right thing. It seems that our intentions in this area have been called into question. We have a fairly straightforward task here: to make a CLR implementation of the Ruby language that is as compatible as we can make it. So when we have a design decision to make, it's driven by "how does the native Ruby implementation handle it"?
We here on the IronRuby team are under no illusion that we will be 100% compatible with the existing Ruby 1.8.x branch. But we will get as close as we can and bend over backwards to ensure that it is so. And I expect that you guys will keep us honest in this regard when it seems like we made a bad design decision.[2]
Pure Ruby code should just work, and code that depends on native platform libraries will have to be ported (either by us porting the native platform libraries or by folks modifying the code to work with our native platform libraries aka the Framework Class Libraries).
Please do speak up when we post code frags, demos (and eventually source). We're really interested in what you have to say !
[1] Keep in mind that we wanted to demo something interesting at MIX (cross-language interop) and that using Ruby (the least mature of our language implementations) as the glue to bind other code together seemed to be the right thing to do. However, at that time we couldn't solicit input from the community since we were in stealth mode.
[2] While I don't think that overloading require was a bad design decision (nobody has given us a concrete example that shows where this breaks their app / library), it's controversial enough and the fix simple enough to do that I have no problem doing it.