扩展类本身内部使用的扩展方法 [英] Using extension methods inside extended class itself

问题描述

比方说，我有一个接口，这样的：

 公共接口ILoggable 
 {
无效日志（Func键<串>消息，Logger.Type型）; 
} 
  

和一些扩展方法，像这样的：

 公共静态类的Logger 
 {
公共静态无效的日志（这ILoggable为loggable，Func键<串>消息）{loggable.Log（消息，Type.Information）; } 
公共静态无效的日志（这ILoggable为loggable，字符串前缀，字节[]数据，INT LEN）{/ *剪断* /} 
公共静态无效的日志（这ILoggable为loggable，异常前）{/ *喀嚓* /} 
 //等等... 
} 
  

然后在任何类CoreService：ServiceBase，ILoggable 或如我实施公共无效日志（Func键<串>消息，Logger.Type型）到任何我喜欢的（public修饰符是一种咩...），并使用所有的扩展方法做实际的记录。

到目前为止好......还是不那么好？有什么不对的做法？如果没有，那么为什么不便：

 赶上（例外前）{
 this.Log（除息）; //这个工程
日志（除息）; //这正好不是
  

解决方案

这似乎是一个合理的方法我本身 ¹ - 但要求明确说明这个只是语言如何能解决扩展方法的一部分。我怀疑这使得语言规范清洁的各个方面，这一要求是充分罕见（和解决方法足够简单），它被认为是更好地与当前的解决方案去比，使事情更加复杂，只是为了避免在五个字符比较少见的情况。

对于简单的名称（部分C＃4规范的7.6.2）会员查找是没有使它雪上加霜足够复杂。不要忘记，简单的名称可以指一个类型或一个类型参数，以及方法。有去有很多在那里了。

当我开始工作，我会检查是否有周围部分7.6.5.2（扩展方法调用），这给所有注释里面的这方面的信息。

---

¹ 在反思，它似乎为奇略实体做记录到的也的要登录其他的东西 - 唯一的一种例外，我希望它看到是当日志是失败的，在这种情况下，记录异常会失败过

Let's say I have an interface, like this:

public interface ILoggable
{
    void Log(Func<string> message, Logger.Type type);
}

And some extension methods, like this:

public static class Logger
{
    public static void Log(this ILoggable loggable, Func<string> message) { loggable.Log(message, Type.Information); }
    public static void Log(this ILoggable loggable, string prefix, byte[] data, int len) { /* snip */ }
    public static void Log(this ILoggable loggable, Exception ex) { /* snip */ }
    // And so on...
}

Then in any class CoreService : ServiceBase, ILoggable or such I implement that public void Log(Func<string> message, Logger.Type type) to whatever I like (public modifier being kind of meh...) and use all the extension methods to do actual logging.

So far so good... or not so good? Is there something wrong with this approach? If not, then why the inconvenience:

catch (Exception ex) {
    this.Log(ex); // this works
    Log(ex); // this goes not

解决方案

It seems like a reasonable approach to me in itself¹ - but the requirement to explicitly state this is just part of how the language works around extension methods. I suspect this makes aspects of the language specification cleaner, and this requirement is sufficiently rare (and the workaround sufficiently easy) that it was felt to be better to go with the current solution than to make things more complicated just to avoid five characters in a relatively rare scenario.

Member lookup for simple names (section 7.6.2 of the C# 4 spec) is complicated enough without making it worse. Don't forget that the simple name can refer to a type or a type parameter, as well as a method. There's a lot going on there already.

When I get to work I'll check if there are any annotations around section 7.6.5.2 (extension method invocation) which give "inside information" about this.

---

¹ On reflection, it does seem slightly odd for the entity doing the logging to also want to log other things - the only kind of exception I'd expect it to see would be when the logging is failing, in which case logging the exception would fail too.

这篇关于扩展类本身内部使用的扩展方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！