它的互操作性很差。例如，考虑这个c# - f#的例子

C#:

public class Class1
{
    public static void Foo(Func<object, string> f)
    {
        Console.WriteLine(f.Method.GetParameters()[0].Name);
    }
}

F#:

Class1.Foo(fun yadda -> "hello")

结果:

打印“arg”(不是“yadda”)。

因此，库设计者应该避免这些“滥用”，或者至少提供一个“标准”的重载(例如，将字符串名作为一个额外的参数)，如果他们想在。net语言之间有良好的互操作。

如果方法(func)名称选择得当，那么这是避免维护头痛的好方法(例如:添加一个新的func，但忘记将其添加到函数参数映射列表中)。当然，你需要对它进行大量的文档记录，你最好从该类函数的文档中自动生成参数的文档……

的确，它看起来像Ruby =)，至少对我来说，使用静态资源进行以后的动态“查找”不适合api设计的考虑，希望这个聪明的技巧是可选的api。

当你不需要添加键来设置值时，我们可以继承(或不继承)IDictionary并提供一个像php数组一样的索引器。它将是.net语义的有效使用，而不仅仅是c#，并且仍然需要文档。

希望这能有所帮助

我认为这不比“魔术弦”好多少。在这方面，我也不太喜欢匿名类型。它需要一种更好的强类型方法。

不，这当然不是常见的做法。这是违反直觉的，没有办法只看代码来弄清楚它是做什么的。你必须知道它是如何被使用的才能理解它是如何被使用的。

而不是使用委托数组提供属性，链接方法将更清晰，性能更好:

.Attribute("style", "width:100%;").Attribute("class", "test")

虽然输入起来有点费劲，但它清晰直观。

这不仅在一个层面上是可怕的。不，这一点也不像露比。这是对c#和。net的滥用。

关于如何以更直接的方式实现这一点，已经有许多建议:元组、匿名类型、流畅接口等等。

它之所以如此糟糕，是因为它只是为了自己的利益而幻想:

What happens when you need to call this from Visual Basic? .Attributes(Function(style) "width:100%") It's completely counter intuitive, and intellisense will provide little help figuring out how to pass stuff in. It's unnecessarily inefficient. Nobody will have any clue how to maintain it. What is the type of the argument going in to attributes? is it Func<object,string>? How is that intention revealing? What is your intellisense documentation going to say, "Please disregard all values of object"?

我认为你完全有理由感到厌恶。