2009-10-26 64 views
4

我最近參加了Code Camp 12,那裏有一位演講者說C#4.0中新的dynamic關鍵字應該只能用於與動態語言交互。我認爲他還表示,與正常反思相比(這本身有點慢),它有點慢。動態關鍵字是否僅用於動態語言?

但後來我聽說Scott Hanselman提到動態關鍵字「使反射不那麼痛苦」。

那麼,爲了反映不是來自動態代碼的對象,使用dynamic關鍵字是可以接受的嗎?

回答

7

我會說「不」,但不要開始瘋狂地使用它。實際上,dynamic是,從我已經基準,更快比基本反思,因爲它保留代表(而不是使用反射Invoke所有的時間)。特別是,兩種方法的長處是:

  • 調用到通用的方法(MakeGenericMethod等就是這麼痛苦)
  • 呼籲運營商

不過,也有使用,你需要用接口等做什麼辦法;在非動態類型上的dynamic實際上相當於鴨子打字。這在非常有限的一組場景中很有用;主要是:接口將是首選。不要排除他們。

dynamic的缺點是有用的(不寫瘋狂的代碼),你需要知道在編譯時的名稱;往往不是這樣,或者我們不會在這個泡菜!當您只在運行時知道名稱時,有其他選項(Expression,Delegate.CreateDelegate,「HyperDescriptor」,DynamicMethod等)以快速方式訪問數據。

4

如果您覺得您需要鴨子打字,並且不需要編譯時安全類型,請繼續並使用動態。我確信會有一些新的用法在C#only代碼中彈出(例如使用ExpandoObject查詢XML等動態數據源)。我確定大量的新用法將是多餘的,就像泛型的大量使用只是更復雜的表示多態的方式一樣。

關於性能,.NET 4中的DLR正試圖使動態類型「快速」。與往常一樣,如果速度夠快,那麼當您開始分析應用程序時,您會發現這些東西。

2

據我所知,在C#中引入dynamic關鍵字的主要原因是爲了更容易與COM對象進行交互操作。但當然,它可以用於反射...

1

我不得不說,「不」。請看http://haacked.com/archive/2009/08/26/method-missing-csharp-4.aspx以獲得較少預期用途的示例。

動態關鍵字顯然是爲了使COM和動態語言更易於使用,但這並不意味着我們應該將它限制在這些區域。就性能而言:記住它,但在出現性能問題之前不要關注它。 (這是那些低級別的細節是不太可能影響到高層次的設計選擇,可以削弱的表現,你甚至開始前一個。)

編輯

此外,任何良好的語言設計者是知道的人們會以意想不到的方式使用語言功能。這與本次討論特別相關,因爲他們提供了一個能夠實現動態行爲的界面。他們有目的地允許人們將任何東西都吸引到「動態」關鍵字功能中。

2

那麼,答案是動態關鍵字是用於interop,但不僅僅是動態語言interop。 COM互操作只是一個例子。 C#團隊已經修改了COM interop以使用此功能,這使得interop變得更加容易。我最近看到ASP.NET MVC Views正在做類似的事情。

我也發佈了一個示例,顯示動態關鍵字的另一個用例: Dynamic in C# 4.0: Creating Wrappers with DynamicObject。這些正是Freed所談論的例子類型:簡化與XML數據的互操作。