Esta es una de las dos cosas que se supone que debe hacer el Dynamic Language Runtime: todo el mundo cree que el DLR es solo para los implementadores del lenguaje para facilitar la implementación de lenguajes dinámicos en la CLI. Pero, también es para los escritores de aplicaciones, para que sea más fácil alojar lenguajes dinámicos en sus aplicaciones.
Antes del DLR, cada idioma tenía su propia API de alojamiento. Ahora, el DLR tiene una standardized hosting specification que funciona igual para todos los lengua, y con el apoyo de objetos de tipado dinámico en C# y VB.NET 4 10, se hace más fácil que nunca:
// 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
Aquí puede ver las cosas pasando por todas las direcciones posibles. El código C# está llamando a un método en el objeto Ruby que ni siquiera existe y el código Ruby está iterando sobre una matriz .NET e imprimiendo su contenido a la consola.
No ve el reverso porque normalmente no se realiza al revés. Yo diría que ocurre la misma situación con Python/C y Jython/Java. – Min
@Min, C y Python funciona en ambos sentidos. De hecho, mi introducción a Python fue incrustrarlo en una aplicación C. –