爲什麼「動態」需要特定於語言的運行時組件？

Microsoft.CSharp需要使用dynamic功能。
我明白裝配中有粘合劑，評估者和助手。
但爲什麼它必須是語言特定的？
爲什麼選擇Microsoft.CSharp而不是Microsoft.Dynamic或System.Dynamic？爲什麼「動態」需要特定於語言的運行時組件？

請解釋。
假設我們有d.x其中d是dynamic。
C＃編譯器
1.適用於C＃語言規則
2.獲取「屬性或字段訪問」
3.發射（figurally）Binder.GetPropertyOrField（d，「X」）
現在，被要求引用微軟.CSharp可能會讓人認爲語言不可知的綁定器無法處理這種情況，而C＃ - 只有某些東西通過編譯得到了方法，並且需要特殊的庫。
編譯器有一個糟糕的一天？

來源

2014-10-30 Leonid

因爲它是針對[System.Dynamic]（http://msdn.microsoft.com/zh-cn/library/system.dynamic（v = vs.110）.aspx）編譯的C＃特定運行時編譯器部件），基本上。 – CodeCaster 2014-10-30 10:10:22

@CodeCaster當然，當然。但爲什麼還有一些東西需要「未編譯」來需要特定於語言的運行時編譯器部分？你有一個例子嗎？ – Leonid 2014-10-30 10:35:07

對於你的第一個問題，它是語言特定的，因爲它需要。

在C＃中，您調用的參數太多的方法會出錯。在Javascript中，額外的參數被忽略。在C＃中，你訪問一個不存在的成員，並得到一個錯誤，而在Javascript中，你得到undefined。即使您發現了所有這些不同的功能集，並將其全部放入System.Core中，本月的下一個語言時尚肯定會有一些它不會支持的超級整潔功能。最好靈活一點。

There is .NET Core中的常用代碼，位於System.Dynamic和System.Runtime.CompilerServices命名空間下。它不是全部都是常見的。

至於第二個問題，對「特殊的C＃庫」的需求當然可以通過內聯轉換這些語言特定的行爲來消除，但爲什麼？這將不必要地膨脹你的IL代碼大小。每次您需要閱讀一個號碼時，您都不要編寫自己的Int32.Parse也是一樣的理由。

來源

2014-10-31 06:53:24

謝謝，我想我明白了你的觀點。程序可能足夠複雜，從將行爲提取到單獨的程序集中獲益很多。沒有理由不在框架內託管它（除了可移植性和向後兼容性問題）。 – Leonid 2014-10-31 09:20:35

我能想到的一個原因 - 從第一天開始，Visual Basic.NET已經有late binding了，主要是圍繞它如何與COM的接口進行互操作 - 所以如果他們想要一個語言不可知的綁定器，他們不得不採用Visual Basic規則 - 包括該成員查找僅適用於Public成員。

顯然，C＃的設計者並不想這麼嚴格。您可以通過動態引用調用這個類的DoStuff方法從C＃：

public class Class1 
{ 
    internal void DoStuff() 
    { 
     Console.WriteLine("Hello"); 
    } 
}

而試圖通過Visual Basic的Object導致MissingMemberException在運行時調用相同。因此，因爲C＃設計人員並不是第一批到達晚期綁定方的人，他們可以跟隨Visual Basic的領導或者他們可以說「每種語言都有自己的規則」 - 他們跟隨後者。

來源

2014-10-31 06:48:07

然而，擁有自己的規則是可以理解的，它不會立即自動將我們（至少是我）引向另一個程序集。另外，我在閱讀你的答案時得到了一個印象，VB特定的綁定器（唯一的一點）駐留在覈心庫中。是這樣嗎？ – Leonid 2014-10-31 09:33:48

爲什麼「動態」需要特定於語言的運行時組件？

回答

相關問題