为什么从扩展类中调用扩展方法需要'this'关键字

一尘不染

为什么从扩展类中调用扩展方法需要'this'关键字

我为ASP.NET MVC ViewPage创建了扩展方法，例如：

public static class ViewExtensions
{
    public static string Method<T>(this ViewPage<T> page) where T : class
    {
        return "something";
    }
}

从View派生此方法时（源自ViewPage），除非出现使用关键字调用它的错误，否则会出现错误“
CS0103：名称“方法”在当前上下文中不存在 ” this：

<%: Method() %> <!-- gives error CS0103 -->
<%: this.Method() %> <!-- works -->

为什么this需要关键字？还是没有它就可以工作，但是我缺少了什么？

（我认为此问题一定是重复的，但找不到）

更新：

正如Ben Robinson所说，调用扩展方法的语法只是编译器糖。那么为什么编译器在不需要this关键字的情况下不能自动检查当前类型的基本类型的扩展方法呢？

阅读 272

2020-05-19

共1个答案

一尘不染

几点：

首先， 不需要 提议的功能（在扩展方法调用上隐式的“
this。”）。扩展方法对于LINQ查询理解以我们想要的方式工作是必不可少的。接收者总是在查询中说明，因此不必支持隐式的使LINQ工作。

其次，此功能与更通用的扩展方法设计背道而驰：也就是说，扩展方法 使您可以扩展无法扩展自己的类型
，要么是因为它是一个接口并且您不知道实现，要么是因为您做了知道实现但没有源代码。

如果你是在场景中你使用的扩展方法的类型 该类型中 ，那么你就可以访问源代码。 那么，为什么首先使用扩展方法？
如果您可以访问扩展类型的源代码，则可以自己编写一个 实例方法
，然后完全不必使用扩展方法！然后，您的实现可以利用对对象的私有状态的访问权限，而扩展方法则不能。

在您可以访问的类型中更轻松地使用扩展方法，鼓励使用扩展方法而不是实例方法。扩展方法很棒，但是如果有实例方法，通常最好使用实例方法。

鉴于这两点，语言设计者不再需要负担解释该功能为何不存在的负担。现在由您来解释为什么 应该这样做
。功能具有巨大的成本。此功能不是必需的，它违背了扩展方法的既定设计目标。我们为什么要承担实施成本？说明此功能启用了哪些引人注目的重要方案，我们将在将来考虑实施。我看不到任何令人信服的重要场景可以证明这一点，但是也许我错过了一个。

2020-05-19