为什么在扩展类中调用扩展方法时需要'this‘关键字
我已经为ASP.NET MVC ViewPage创建了一个扩展方法，例如：
public static class ViewExtensions
{
public static string Method<T>(this ViewPage<T> page) where T : class
{
return "something";
}
}当从视图(从ViewPage派生)调用此方法时，除非我使用this关键字来调用它，否则我会收到错误消息"CS0103：' method‘的名称在当前上下文中不存在“：
<%: Method() %> <!-- gives error CS0103 -->
<%: this.Method() %> <!-- works -->为什么需要this关键字？或者没有它也能工作，但我遗漏了什么？
(我想这个问题肯定有重复，但我找不到)
更新
作为Ben Robinson says，调用扩展方法的语法只是编译器的糖。那么为什么编译器不能在不需要this关键字的情况下自动检查当前类型的基类型的扩展方法呢？
回答 6
Stack Overflow用户
发布于 2010-08-18 22:17:43
以下是几点：
首先，建议的功能(隐含“this”。在扩展方法调用上)是不必要的。扩展方法是LINQ查询理解以我们想要的方式工作所必需的；接收者总是在查询中声明的，所以没有必要支持隐式的this来使LINQ工作。
其次，该功能与扩展方法的更一般设计相反:即，扩展方法允许您扩展不能自己扩展的类型，要么是因为它是一个接口而您不知道实现，要么是因为您确实知道实现但没有源代码。
如果您所处的场景是对该类型中的某个类型使用扩展方法，那么您确实有权访问源代码。那么，为什么首先要使用扩展方法呢？如果您可以访问扩展类型的源代码，那么您可以自己编写一个实例方法，这样您就完全不需要使用扩展方法了！然后，您的实现可以利用对对象的私有状态的访问，这是扩展方法所不能做到的。
通过在您有权访问的类型中更容易地使用扩展方法，可以鼓励使用扩展方法而不是实例方法。扩展方法很棒，但通常最好使用实例方法(如果您有实例方法)。
考虑到这两点，语言设计者不再有责任解释为什么这个特性不存在。现在轮到你来解释为什么应该这样做了。功能有巨大的成本与之相关。这个特性不是必需的，并且违背了扩展方法规定的设计目标；为什么我们要承担实现它的成本？解释此功能支持哪些引人注目、重要的场景，我们将考虑在将来实现它。我没有看到任何令人信服的重要场景来证明它的合理性，但也许有一个我遗漏了。
Stack Overflow用户
发布于 2010-08-18 18:16:44
如果没有它，编译器只会将其视为静态类中的静态方法，静态类将page作为其第一个参数。即
// without 'this'
string s = ViewExtensions.Method(page);与
// with 'this'
string s = page.Method();Stack Overflow用户
发布于 2010-08-18 19:25:09
在实例方法上，'this‘被隐式地传递给每个方法，因此您可以访问它提供的所有成员。
扩展方法是静态的。通过调用Method()而不是this.Method()或Method(this)，您并没有告诉编译器要传递给方法什么。
你可能会说，‘为什么它不直接意识到调用对象是什么，并将其作为参数传递？’
答案是扩展方法是静态的，可以从静态上下文中调用，在静态上下文中没有“this”。
我猜他们可以在编译过程中检查这一点，但老实说，这可能是很大的工作，但回报非常少。老实说，我认为去掉扩展方法调用的一些显性并没有什么好处。事实上，它们可能会被误认为是方法，这意味着它们有时会非常不直观(例如，不会抛出NullReferenceExceptions)。我有时认为他们应该为扩展方法引入一种新的“管道转发”风格的运算符。
https://stackoverflow.com/questions/3510964
复制相似问题