C'est l'une des deux choses que le Exécution du langage dynamique est censé faire : tout le monde pense que le DLR n'est destiné qu'aux implémenteurs de langages pour faciliter l'implémentation de langages dynamiques sur le CLI. Mais il est également destiné aux auteurs d'applications, pour faciliter l'intégration des langages dynamiques dans leurs applications.
Avant le DLR, chaque langue avait sa propre API d'hébergement. Désormais, le DLR dispose d'une spécification d'hébergement standardisé qui fonctionne de la même manière pour chaque et avec la prise en charge des objets typés dynamiquement dans C# 4 et VB.NET 10, c'est plus facile que jamais :
// 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 = globals.MethodMissingDemo.@new();
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
Ici, on voit des trucs qui passent dans toutes les directions possibles. Le code C# appelle une méthode sur l'objet Ruby qui n'existe même pas et le code Ruby itère sur un tableau .NET et imprime son contenu dans la console.