C#若是把A.new()編譯成new A()

原因

對於初次接觸某個第三方庫的C#開發者，假如要調用裏面一個方法，發現須要一個A類型的實例做爲參數，怎麼得到這個實例呢?

我想大多數人會先嚐試new A吧:

若是沒有，可能會嘗試輸入A.看看有沒可能的構造方法:

 要 若是尚未，那通常要經過其餘方式得到了（子類、其餘方法的返回結果等）。就此打住，由於後面的不在此文討論範圍。

我就鬱悶了，爲什麼要我輸入一次new以後發現沒有，而後再次輸入A.呢？

我指的是，最好讓C#編譯器支持這樣的語法糖：A.new() 跟new A()等價。

 

本文不適合的閱讀對象

• 文檔帝：萬事必先看文檔的人，本文說明的東西與你無關。

• 鍵盤帝：不使用VS或者相似的智能提示的用戶，本文說明的東西對你沒什麼影響。

 

好處是什麼？

「你不以爲輸入一次new A以後刪掉再輸入A.這個過程很傻嗎？」

只需輸入A.便可知道是否有構造函數，相似A.create這樣的工廠方法，或者像A.instance這樣的單例對象，列在一塊兒更方便對比。

另一個好處是，A.new 能夠經過匹配參數類型來賦值給一個委託實例(Delegate)。

 

有什麼可能出現的問題?

• 「萬一用戶想建立一個名爲new的方法怎麼辦？」

毫無疑問，這種方式可能引發誤解，覺得這是一個靜態方法，至關於類空間的命名被污染了。不過這種的說法是不成立的。

首先，假設A是個類型，當看到A.x()的時候，你以爲這是什麼？事實上，你徹底不能肯定他是啥，多是一個靜態方法，也多是靜態屬性，還多是靜態字段。因此，A.new()究竟是什麼自己就沒可誤解的地方。

其次，當用戶想定義一個名爲new的方法，實際上也是不可行的：

由於new是個關鍵字，要做爲方法名的話，前面須要加@

調用時@也是不可省略的

因此，A.new()原本就是不能編譯經過的，跟現有語法體系沒有衝突。

對比起來，C#的自動屬性纔是真正的「污染類空間命名」，而附加屬性也必定程度影響開發者的慣性思惟，A.new()比起這些真的是小巫見大巫，語法糖而已。

 

• 「反射的時候，會有問題嗎？」

我以爲不會，Type.GetMethod的時候，原本就不包含構造函數。抽象類、接口、枚舉這些東西，有new沒new自己就是規則定好的，跟現有語法不混淆。

至於各類IDE的智能提示，做爲規則支持就是了。

 

• 「假如A的名字好長好長，就沒new A()方便」

是的，當輸入B.f(new空格後，能夠看到A在列表裏直接選擇回車，這樣敲的字符數是不多的。因此，new A()的方式徹底能夠保留。另外，提供一個智能提示，還記得事件綁定的那個snippet嗎？

 

 

待補充

到此，我仍是沒想到把A.new()編譯成new A()有什麼壞處，關於這個建議若是各位有其餘想法，不妨留個言?