关于.net：返回这个而不是虚空有什么不利吗？

假设没有返回void，而是返回对类的引用，即使它没有任何特定的语义意义。在我看来，它会给你更多关于如何调用方法的选项，允许你以流畅的界面风格使用它，我不能真正想到任何缺点，因为你不需要做任何事情带有返回值(甚至存储它)。

因此，假设您处于要更新对象然后返回其当前值的情况。
而不是说

你可以把两条线结合起来说

编辑：我一想到就问下面，回想起来，我同意它可能是不必要的和复杂的，但是关于归还这个而不是无效的我的问题就在于此。

在一个相关的说明中，你们怎么看待这种语言包括一些新的语法糖：

此运算符的优先级较低，因此myObj.Update()将首先执行，然后在myObj上调用GetCurrentValue()而不是Update的void返回。

基本上我正在想象一个操作员会说"在左边的第一个有效对象上调用操作员右侧的方法"。有什么想法吗？

---

我认为作为一般政策，它根本没有意义。以这种方式链接的方法适用于正确定义的接口，但只有在它具有语义意义时才适用。

你的例子是一个不合适的主要例子，因为它没有语义意义。

同样，使用设计合理的流畅界面也不需要你的语法糖。

流畅的接口或方法链接可以很好地工作，但需要仔细设计。

---

我知道在Java中他们实际上正在考虑为void方法制定这种标准行为。如果你这样做，你不需要额外的语法糖。

我能想到的唯一不利因素是表现。但这很容易衡量。我会在几分钟后回复你的结果:-)

编辑：

返回引用比返回void要慢一点..真是一个惊喜。所以这是唯一的缺点。在调用你的函数时还需要几个滴答。

---

这不是"流畅的接口" - 就像JQuery使用的那样 - 是如何构建的？一个好处应该是代码可读性(尽管http://en.wikipedia.org/wiki/Fluent_interface上的维基百科条目提到有些人发现它不可读)。另一个好处是代码简洁，你不需要在7行代码中设置属性，然后在第8行调用该对象的方法。

Martin Fowler(他在这里创造了这个术语 - http://martinfowler.com/bliki/FluentInterface.html)表示，与方法链接相比，界面更流畅，但是方法链接是一种常用的技术，可以使用流畅的界面。

编辑：
我实际上回到这里编辑我的答案，并补充说，当我看到乔治的评论指出我确实忘记讨论问题的重点时，以任何可衡量的方式返回此而不是无效是没有缺点的。对不起，最初的"毫无意义"漫无边际。

---

我能看到的唯一缺点是它使API稍微混乱。假设您有一些带有remove()方法的集合对象，该方法通常会返回void。现在您想要返回对集合本身的引用。新签名看起来像：

只是查看签名，您不清楚是否返回对同一实例的引用。也许MyCollection是不可变的，你正在返回一个新实例。在某些情况下，就像这里一样，您需要一些外部文档来澄清这一点。

我实际上喜欢这个想法，我相信有一些关于改进Java7中所有void方法的讨论，以返回对'this'的引用，但它最终落空了。

---

NeXTSTEP Objective-C框架曾用于使用此模式。一旦分布式对象(基本上是远程过程调用)被添加到语言中，它就会停止在该框架中 - 返回self的函数必须是同步调用，因为分布式对象系统看到了返回类型并假设调用者需要知道函数的结果。

---

返回"自我"或"此"是一种常见的模式，有时称为"方法链"。至于你提出的语法糖，我不太我不是一个.NET人，但它对我来说似乎并不十分有用。

---

乍一看它可能看起来不错，但是对于一致的界面，您将需要所有方法都返回对此的引用(它有自己的问题)。

假设你有一个类，有两个方法GetA返回它，GetB返回另一个对象：

然后你可以调用obj.GetA()。GetB()，但不能调用obj.GetB()。GetA()，这至少看起来不一致。

使用Pascal(和Visual Basic)，您可以调用同一对象的多个方法。

1 2 3 4

with obj   .GetA();   .GetB(); end with;

此功能的问题在于您可以轻松编写比应该更难理解的代码。另外添加一个新运算符可能会让它变得更难。

---