我看着MvcContrib网格组件,我很着迷,但同时又被网格语法中使用的语法技巧所排斥:

.Attributes(style => "width:100%")

上面的语法将生成的HTML的样式属性设置为width:100%。如果你注意的话,'style'并没有被指定。它是从表达式中参数的名称推导出来的!我必须深入研究这个问题,找到“魔法”发生的地方:

Hash(params Func<object, TValue>[] hash)
{
    foreach (var func in hash)
    {
        Add(func.Method.GetParameters()[0].Name, func(null));
    }
}

因此,代码确实使用了正式的、编译时的参数名称来创建属性名称-值对的字典。生成的语法结构确实非常具有表现力,但同时也非常危险。

lambda表达式的一般用法允许替换所使用的名称而不产生副作用。我在一本书上看到一个例子,上面写着收藏。我知道我可以在我的代码集合中写。ForEach(log => fire。burn (log))它的意思是一样的。但是使用这里的MvcContrib Grid语法,我突然发现代码可以根据我为变量选择的名称主动查找并做出决定!

那么这是c# 3.5/4.0社区和lambda表达式爱好者的普遍做法吗?还是说,我不应该担心一个流氓的诡计特立独行?


当前回答

All this ranting about "horridness" is a bunch of long-time c# guys overreacting (and I'm a long-time C# programmer and still a very big fan of the language). There's nothing horrible about this syntax. It is merely an attempt to make the syntax look more like what you're trying to express. The less "noise" there is in the syntax for something, the easier the programmer can understand it. Decreasing the noise in one line of code only helps a little, but let that build up across more and more code, and it turns out to be a substantial benefit.

This is an attempt by the author to strive for the same benefits that DSL's give you -- when the code just "looks like" what you're trying to say, you've reached a magical place. You can debate whether this is good for interop, or whether it is enough nicer than anonymous methods to justify some of the "complexity" cost. Fair enough ... so in your project you should make the right choice of whether to use this kind of syntax. But still ... this is a clever attempt by a programmer to do what, at the end of the day, we're all trying to do (whether we realize it or not). And what we're all trying to do, is this: "Tell the computer what we want it to do in language that is as close as possible to how we think about what want it to do."

使软件更易于维护、更准确的关键在于,我们能够更接近于用我们内心认为的方式向计算机表达指令。

编辑:我曾经说过“使软件更具可维护性和准确性的关键”,这是一种疯狂的天真和夸张的独角兽观点。我把它改成了“钥匙”。

其他回答

它的互操作性很差。例如,考虑这个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语言之间有良好的互操作。

我几乎没有遇到过这种用法。我认为这是“不合适的”:)

这不是一种常用的使用方式,它不符合一般的约定。当然,这种语法也有优点和缺点:

Cons

代码不是直观的(通常的约定是不同的) 它往往是脆弱的(重命名参数将破坏功能)。 测试起来有点困难(伪造API需要在测试中使用反射)。 如果大量使用表达式,它会变慢,因为需要分析参数而不仅仅是值(反射成本)。

Pros

在开发人员调整到这种语法之后,它的可读性更强。

底线——在公共API设计中,我会选择更明确的方式。

我发现奇数不是因为它的名字,而是因为没有必要;它可以使用匿名类型,并且更加灵活:

.Attributes(new { style = "width:100%", @class="foo", blip=123 });

这是在很多ASP中使用的模式。NET MVC(例如),并有其他用途(注意,如果名称是一个魔法值,而不是特定于调用者,也要注意Ayende的想法)

我属于“语法卓越”阵营,如果他们清楚地记录它,它看起来非常酷,在我看来几乎没有问题!

在我看来,这是对羔羊的滥用。

至于语法辉煌,我发现style=>"width:100%"平原混乱。特别是因为=>而不是=