无法使扩展方法在委托上工作
本文关键字:工作 方法 扩展 | 更新日期: 2023-09-27 18:36:30
考虑下面的例子。如果首先定义该委托类型的变量,我可以调用委托的扩展方法。但是我不能在作为参数传递的委托上调用该扩展方法。我不明白为什么它第一次有效,但第二次不起作用。我做错了什么?
public static class Extender
{
public static Func<String, String> Compose(this Func<String, String> outer, Func<String, String> inner)
{
return input => outer(inner(input));
}
}
public class Demo
{
public void WillingToTakeStringToStringDelegate(Func<String, String> map)
{
// blah
}
public void RunMe()
{
Func<String, String> outer = x => "(outer: " + x + ")";
// this works:
var composition = outer.Compose(x => "(inner: " + x + ")");
Trace.Write(composition("!")); // ---> (outer: (inner: !))
// this doesn't work:
this.WillingToTakeStringToStringDelegate(
(x => "(outer: " + x + ")").Compose(y => "(inner: " + y + ")")
);
}
}
更新
对于@philologon
只要您不介意将lambda分配给变量,那么是的,您可以使用此方法像老板一样创建函数的部分应用程序(currying):
public static class CurryingHelper
{
public static Func<X> Apply<A, X>(this Func<A, X> fun, A a)
{
return () => fun(a);
}
public static Func<B, X> Apply<A, B, X>(this Func<A, B, X> fun, A a)
{
return b => fun(a, b);
}
public static Func<B, C, X> Apply<A, B, C, X>(this Func<A, B, C, X> fun, A a)
{
return (b, c) => fun(a, b, c);
}
public static Func<B, C, D, X> Apply<A, B, C, D, X>(this Func<A, B, C, D, X> fun, A a)
{
return (b, c, d) => fun(a, b, c, d);
}
// etc...
}
public class Demo
{
public void RunMe()
{
Func<Int32, Int32, Int32, Int32> func = (a, b, c) => a - b + c;
var funcA1 = func.Apply(1);
Trace.Write(funcA1(2, 3)); // --> 2
Trace.Write(funcA1.Apply(2).Apply(3)()); // --> 2
}
}
概念没有错,只是执行上有一些技术问题。
关键是x => "(outer: " + x + ")"
不是没有上下文的委托:它是一个 lambda 表达式,可以对应于委托(某种类型)甚至表达式树。因此,必须显式或隐式声明类型,例如
// this works:
this.WillingToTakeStringToStringDelegate(
((Func<string, string>)(x => "(outer: " + x + ")")).Compose(...)
);
这与不能将 lambda 函数分配给隐式类型变量的原因完全相同,例如
var f1 = (string s) => "Hello " + s; // does not work
Func<string, string> f2 = (string s) => "Hello " + s; // works fine
C# 中的 Lambda 表达式本身没有类型。例如,您可以将 lambda 表达式x => x != 0
分配给 Predicate<int>
、 Func<int, bool>
、 Func<long, bool>
或 YourCustomDelegate
。
因此,每当使用 lambda 表达式时,都需要向编译器提供提示,说明应使用哪种委托类型。
例子:
-
这行得通。提示是变量的类型
outer
。Func<String, String> outer = x => "(outer: " + x + ")";
-
这行得通。提示是
Compose
方法的参数inner
的类型。var composition = outer.Compose(x => "(inner: " + x + ")");
-
这不起作用,因为没有为
(x => "(outer: " + x + ")")
提供提示:this.WillingToTakeStringToStringDelegate( (x => "(outer: " + x + ")").Compose(y => "(inner: " + y + ")") );
其他答案是正确的;我只是想指出,设计团队故意选择扩展方法不适用于任何没有类型的表达式 - 因此,lambda,匿名方法,null或方法组或任何动态表达式上没有扩展方法。
事实上,它比这更进一步;点左侧的表达式必须可以通过恒等、隐式引用或装箱转换转换为第一个参数。换句话说:
enum E { }
static class Ext
{
public static E X(this E e) { return e; }
}
// Legal
E e1 = 0;
// Legal
E e2 = e1.X();
// No way José.
E e3 = 0.X();
这不是身份、参考或拳击转换。
这里的语言设计原则是第一位的,没有令人讨厌的惊喜。扩展方法是语言的后期添加,设计团队希望非常小心,不要添加它们以令人惊讶的方式变得适用的情况。
其次,在大多数情况下,C# 的原因与从内到外的表达式类型有关。也就是说,当我们看到x = y
时,我们会独立分析x和y的类型,然后决定分配是否合法。但是对于无类型的表达式,这是颠倒的。对于x = (y)=>{whatever}
我们分析x的类型,然后用它来决定(y)=>{whatever}
是否是合法的右侧,如果是,它是什么类型,以及whatever
中的所有东西是什么类型。 这种对正常顺序的反转导致编译器中有一些非常复杂的代码,没有人急于添加另一种我们必须进行由内而外推理的情况。
最后,由于显然您对咖喱感兴趣,因此您可能会对此感兴趣。
http://blogs.msdn.com/b/ericlippert/archive/2009/06/25/mmm-curry.aspx