我为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:
ViewPage
this
<%: Method() %> <!-- gives error CS0103 --> <%: this.Method() %> <!-- works -->
为什么this需要关键字?还是没有它就可以工作,但是我缺少了什么?
(我认为此问题一定是重复的,但找不到)
更新 :
正如Ben Robinson所说,调用扩展方法的语法只是编译器糖。那么为什么编译器在不需要this关键字的情况下不能自动检查当前类型的基本类型的扩展方法呢?
几点:
首先, 不需要 提议的功能(在扩展方法调用上隐式的“ this。”)。扩展方法对于LINQ查询理解以我们想要的方式工作是必不可少的。接收者总是在查询中说明,因此不必支持隐式的使LINQ工作。
其次,此功能 与 更通用的扩展方法设计背道而驰:也就是说,扩展方法 使您可以扩展无法扩展自己的类型 ,要么是因为它是一个接口并且您不知道实现,要么是因为您做了知道实现但没有源代码。
如果你是在场景中你使用的扩展方法的类型 该类型中 ,那么你 就 可以访问源代码。 那么,为什么首先使用扩展方法? 如果您可以访问扩展类型的源代码,则 可以自己编写一个 实例方法 ,然后完全不必使用扩展方法!然后,您的实现可以利用对对象的私有状态的访问权限,而扩展方法则不能。
在您可以访问的类型中更轻松地使用扩展方法,鼓励使用扩展方法而不是实例方法。扩展方法很棒,但是如果有实例方法,通常最好使用实例方法。
鉴于这两点,语言设计者不再需要负担解释该功能为何 不 存在的负担。现在由您来解释为什么 应该这样做 。功能具有巨大的成本。此功能不是必需的,它违背了扩展方法的既定设计目标。我们为什么要承担实施成本?说明此功能启用了哪些引人注目的重要方案,我们将在将来考虑实施。我看不到任何令人信服的重要场景可以证明这一点,但是也许我错过了一个。