本文翻譯自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上的動態類型系統的細節我會在下面討論。