We removed it for 2 reasons: 1) RubyContext is not a supported public API and can change any time. Hosting APIs on the other hand (i.e. IronRuby.Ruby class) will remain stable. We'll try hard not to introduce breaking changes.
2) RubyContext is not remoting aware while Hosting APIs are. HostingHelpers.GetLanguageContext can be used as a last resort workaround, however there is no guarantee we won't break such usage any time in future by changing RubyContext. What methods on RubyContext does IronRuby.Rack need? If there is some feature that should be exposed via Hosting API we should add it. Tomas From: Jimmy Schementi Sent: Monday, March 08, 2010 2:27 AM To: Tomas Matousek Cc: 'ironruby-core@rubyforge.org' Subject: RE: IronRuby.Ruby.GetExecutionContext removed Tomas, What reasons did we have for removing this in the first place? It also affects anyone writing code that uses our Ruby types/library methods in their own code (for providing the correct types to Ruby code); IronRuby.Rack does this. As a work-around, are we really expecting people to use Microsoft.Scripting.Hosting.Providers.HostinHelpers.GetLanguageContext directly? ~Jimmy From: Jimmy Schementi Sent: Thursday, March 04, 2010 5:32 PM To: Tomas Matousek Cc: ironruby-core@rubyforge.org Subject: IronRuby.Ruby.GetExecutionContext removed including the mailing list as people might run into this ... Tomas, I know you recently removed IronRuby.Ruby.GetExecutionContext; is there any other way to get to the instance of IronRuby.Ruby.RubyContext? I'd presume anyone hosting IronRuby and define ruby global variables was using DefineGlobalVariable; so they'd run into this. Looks like ScriptEngine.LanguageContext is now internal as well ... I specifically found this while updating DLRConsole, and simply removed the places where I was using ruby global variables.
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
