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()有什么坏处，关于这个建议若是各位有其余想法，不妨留个言?