Microsoft.CSharp需要使用dynamic
功能
我知道装配中有粘合剂,评估者和帮助者
但为什么它必须是语言特定的呢?
为什么选择Microsoft.CSharp而不是Microsoft.Dynamic或System.Dynamic?
请解释。
假设我们d.x
d
为dynamic
。{。}
C#编译器
1.适用C#语言规则
2.获得“财产或现场访问”
3.发出(图形)Binder.GetPropertyOrField(d,“x”)
现在,被要求引用Microsoft.CSharp可能会让人觉得语言无关的绑定器无法处理这种情况,并且C#-only 某些通过编译得到了它并需要特殊的库。
编译器有一个糟糕的一天?
答案 0 :(得分:2)
我能想到的一个原因 - Visual Basic.NET从第一天开始就有late binding,主要是围绕它如何与COM IDispatch
接口进行互操作 - 所以如果他们想要一个与语言无关的绑定器,他们必须采用Visual Basic规则 - 其中包括成员查询仅适用于Public
成员。
显然,C#设计师并不想这么严格。你可以打电话给这个班级'来自C#的DoStuff
方法通过动态参考:
public class Class1
{
internal void DoStuff()
{
Console.WriteLine("Hello");
}
}
尝试通过Visual Basic Object
调用相同内容时,会在运行时生成MissingMemberException
。
因为C#设计师并不是第一个到达后期绑定派对的人,他们可以按照Visual Basic的主导,或者他们可以说"每种语言都有自己的规则和" #34; - 他们和后者一起去了。
答案 1 :(得分:2)
对于您的第一个问题,它是特定于语言的,因为它需要。
在C#中,调用参数太多的方法会出现错误。在Javascript中,额外的参数被简单地忽略。在C#中,您访问不存在的成员并获得错误,而在Javascript中,您获得undefined
。即使您发现所有这些不同的功能集并将其全部放入System.Core,本月的下一个语言时尚肯定会有一些它不支持的超级功能。最好是灵活。
是 .NET内核中的公共代码,位于System.Dynamic和System.Runtime.CompilerServices名称空间下。它不可能都是常见的。
关于你的第二个问题,当然可以通过内联转换这些特定于语言的行为来删除对“特殊C#库”的需求,但为什么呢?这将不必要地膨胀您的IL代码大小。每次你需要阅读一个数字时,你都不会自己写Int32.Parse
这就是同样的理由。