c＃中動態特性運行時的未來？

Question

因此，c＃已經發展爲靜態類型語言，並且在利用.net框架開發業務線應用程序方面不僅僅是完美的工作。

現在，顯然，最近過去，微軟已經開始向其他基本範式邁進，而c＃和.net從來沒有真正聲稱是直到最近的過去。

其中一個是DLR

好的語言divercity - 偉大的，我在想，只是現在它看起來像我不得不改變我的想法的方式，當我寫我的業務實體類，如果我想利用這個功能......這很酷，而且我都在學習新的功能。但在此之前，我在這方面對受尊敬的社區有一些問題。現在爲了澄清，我對CLR和DLR的應用更感興趣。

所以我們開始：

1. 你的意見，是DLR一個可行的功能，desrves將在從企業的商業軟件開發的角度看？意思是說，c＃是否真的需要將它作爲一種功能繼續做它正在做的事情，或者在那時切換到標準的動態類型語言會更有意義嗎？

2. 將開發和編寫代碼與CLR和DLR結合在商業適用性方面表現出色嗎？具體的例子將是我最看重的。

3. 好處。

現在MSDN這樣說：

Provides Future Benefits of the DLR and .NET Framework Languages implemented by using the DLR can benefit from future DLR and .NET Framework improvements. For example, if the .NET Framework releases a new version that has an improved garbage collector or faster assembly loading time, languages implemented by using the DLR immediately get the same benefit. If the DLR adds optimizations such as better compilation, the performance also improves for all languages implemented by using the DLR.

那麼大，但究竟如何？如果我只是升級我的框架，我不會得到相同的結果嗎？爲什麼我需要在DLR中寫入？

1. 你可以發佈代碼示例來展示DLR可以比常規c＃做更好的jon嗎？

2. 值得去了解它是一個可銷售的.net工程師，還是說它或多或少是一種等規的特徵，只是說：「哦，我們比Ruby好，BC我們也可以做得更多」？

3. 在應用程序中組合這些2或僅使用DLR的開銷是多少？發展？

4. DLR可以和f＃一起使用嗎？

問候。

Answer 1

可能值得說明的是，DLR是CLR頂層的API，用於降低實現動態語言功能的標準。您可以像IronPython，IronRuby，Clojure和其他語言一樣使用它來實現您的語言。您可以像C＃或VB一樣使用它來實現動態呼叫站點緩存（搜索內聯多態緩存以獲得有關概念的一般信息）。因此，C＃添加了'dynamic'關鍵字，並且它使用DLR的CallSites，綁定器，DynamicMetaObjects等來實現此語言功能。

是的，DLR是一個可行的功能，對C＃有意義。對於COM互操作，無類型數據源（DB，XML等）以及網頁背後的輕量級語法（例如，button.text =「yo」），C＃已經落後於VB。當我喜歡某種語言時，發現它通常很有用，或者調整了我的實力，我喜歡儘可能地使用該語言。我不想拼湊在一起，並通過使用多種語言在我的解決方案中創建維護開銷，除非我真的需要這樣做。 C＃的'動態'讓我能夠以更簡單更快捷的方式在C＃中完成我已經可以做的事情，而且這肯定意味着我不必求助於純粹的動態語言或可選的顯式類型語言，以便更容易地編寫更多代碼現在的情況。

如果您試圖將動態類型功能添加到語言或大型，豐富的系統中，使用DLR開發代碼將會大放異彩。正如人們經常引用的，「任何非常複雜的...程序都包含一個...... Lisp的臨時......實現」。如果你發現你需要對數據或對象進行一些動態類型的訪問，並計算一些操作意味着什麼給了一些輸入，並且想要將該操作緩存在程序中該位置的後續類似計算中，那麼DLR可以幫助你做到這一點以較低成本的方式。事情是，你可能甚至不需要在這個級別使用DLR，因爲C＃已經爲你引入了「動態」。但是，您可能希望在代表數據源的某些對象上實現IDynamicMetaObjectProvider，以便它們可以參與C＃的動態分派電話所執行的綁定操作。例如，如果XmlElement實現了IDMOP，那麼您可以編寫如下代碼： dynamic x = source.GetXmlElement（...）; ... x.Customers [I] .Address.City ==「伊利」 ...

的好處是在書面對抗由他們的性質固有的動態的，而不是讓數據或對象的代碼更高程度的表達力的來表達複雜的中間類型聲明並執行很多o.GetBlahByName（「whatever」）調用。

您從DLR文檔引用的段落是關於建立在DLR上的語言實現。當然，您的應用程序也可以獲得好處。例如，關於IronPython如何加快速度不僅僅是因爲DLR的出現，還因爲CLR本身確實起作用，間接地改進了DLR上的IronPython實現。

除非您需要爲您的語言或系統添加一些緩存的動態訪問權限，否則不要去學習DLR。大多數人不會在這種複雜程度下進行編碼。大多數人使用語言和框架，很少有人實現它們。 F＃可以使用DLR，但一個常見的誤解是F＃是一種動態語言。不是這樣。它是嚴格靜態類型的，但並不是在所有情況下都明確地輸入，這就是讓人困惑的原因。由於大量使用類型推理和顯着的空白，它在語法上看起來很輕巧。如果F＃有一天決定添加像C＃那樣的「動態」類型模型，那麼使用DLR便於實現並與C＃互操作，.NET上的動態語言，動態庫和框架等

比爾