本文翻译自IronPython的作者Jim Hugunin的个人博客，原文链接为 http://blogs.msdn.com/hugunin/archive/2007/05/02/the-one-true-object-part-1.aspx
我非常兴奋，因为看到了大家想要了解DLR的热情。我也要说对不起，因为现在现没有完整的文档给你们。如果你想要一分详尽的文档和API，你还要等一段时间。如果你喜欢源代码和这个Blog，那么你可以开始在这里浪费点时间了。如果你只是想尝试一下代码，去下载silverlight,开始探索构建在DLR之上的Python和JavaScript吧。
今天我的设计笔记是关于动态类型系统的。动态类型系统是DLR的三个关键组件之一——而且我认为是最关键的。DLR的里程牌便是支持一个共享的动态类型系统。这使得动态语言之间可以容易而自然地相互交流，共享代码。同样重要的是我们使这些动态语言能够工作在现有的强大的静态语言平台上，例如VB.NET和C#.我们要确保现有的和以后为.NET写的库都能够为动态语言服务。为了实现这种互操作，有一种标准的模式——通过包装(wrapper)和管制层。我利用这个模式实现了Jython——JVM上的Python。
注意到在这个模式中，Python类型存在于它们自己的小世界中(桔色部分),而且对于每个底层的类型，我都需要把它放到一个Python特性的包装类中。如果只是想支持一种语言，这个模式是很好的。在我上面这个例子中，我只写Python代码，那么所有我处理的对象都是PyObject，它们可以相互工作的很好，通过它们的Python特性。可是当你想支持多种语言的集成时，这个模式就会崩溃了。在这种情况下，每一次一个对象从一种语言移动到另一种语言时，它需要从源语言去包装，再包装到目标语言。这会带来明显的性能问题，当跨语言调用时包装类被创建被丢弃。
这个包装的方法还有更深层次的问题。一个挑战便是我们要指出需要传递的对象。例如，Python中有PyString，当调用C#函数时需要一个对象时，是应该传递PyString还是解包装为String？这些微妙的问题从来没有一个好的答案。更糟的，在程序员后面静悄悄的包装和解包装的过程中，对象同一性的缺失会产生更讨厌的问题。
大多数流行的用C实现的动态语言同样使用包装模式。当用C来实现动态语言时，这种包装是很合理的，因为C指针没有携带任何运行时有用的类型信息，所以需要一个包装层来提供需要的运行时类型信息。但是，托管的运行时，例如CLR，为它们的标准对象提供了丰富的运行时类型信息，所以应该可能直接使用这个对象，没有包装和和管制带来的混乱和运行代价。我们在DLR中使用了这一点，这也是我们实际应用的类型系统。
这意味着DLR中的所有对象和CLR的对象是完全一致的。我们添加了更好的支持公共动态操作的特性，但我们仍然深深地植根于.NET上现存的库和语言。如果想要真正的使语言之间无缝整合，我们需要一个统一的类型系统，不用管制和包装层。
现在我们到达了第一部分的终点，我担心这也许会令人不满意。到现在为止，我们关于动态类型系统的解释就是，我们使用的对象和元数据完全是CLR上已经使用的静态的类型化的对象。好吧，今天在网上的发布不会让我停止。更多关于CLR上的动态类型系统的细节我会在下面讨论。