Questa è una delle due cose che deve fare il Dynamic Language Runtime: tutti pensano che il DLR sia solo per implementatori linguistici che semplificano l'implementazione di linguaggi dinamici sulla CLI. Ma è anche per gli scrittori di applicazioni, per rendere più facile l'hosting di lingue dinamiche nelle loro applicazioni.
Prima del DLR, ogni lingua aveva la propria API di hosting. Ora, il DLR ha un standardized hosting specification che funziona allo stesso modo per ogni lingua, e con il supporto per gli oggetti dinamicamente tipizzati in C# e VB.NET 4 10, diventa più facile che mai:
// MethodMissingDemo.cs
using System;
using IronRuby;
class Program
{
static void Main()
{
var rubyEngine = Ruby.CreateEngine();
rubyEngine.ExecuteFile("method_missing_demo.rb");
dynamic globals = rubyEngine.Runtime.Globals;
dynamic methodMissingDemo = [email protected]();
Console.WriteLine(methodMissingDemo.HelloDynamicWorld());
methodMissingDemo.print_all(args);
}
}
# method_missing_demo.rb
class MethodMissingDemo
def print_all(args)
args.map {|arg| puts arg}
end
def method_missing(name, *args)
name.to_s.gsub(/([[:lower:]\d])([[:upper:]])/,'\1 \2')
end
end
Qui sotto potete vedere roba farsi passare in tutte le direzioni possibili. Il codice C# sta chiamando un metodo sull'oggetto Ruby che non esiste nemmeno e il codice Ruby sta iterando su un array .NET e ne sta stampando il contenuto nella console.
fonte
2009-11-06 02:01:16
Non si vede il contrario perché in genere non viene eseguito al contrario. Direi che la stessa situazione si verifica con Python/C e Jython/Java. – Min
@Min, C e Python funzionano in entrambe le direzioni. In effetti, la mia introduzione a Python lo incorporava in un'app C. –