来源于控制流的COMEFROM

Question

根据wikipedia所述，COMEFROM流程控制被认为是一个笑话、难以阅读或者直接有害。我想在AOP场景中这样的特性会非常有用（例如：在方法中添加记录器而无需添加记录器调用到方法中）。

这种控制结构不明显的缺点是否超过了其潜在的有用性？还有其他需要考虑的缺点吗？

因为this而提出此问题。

- Goran

---

从主题行来看，我猜想我可能是原因 :) - Jon Skeet

以这种方式添加日志，实际上是在说控制流非常难以跟踪并不重要，因为您不需要了解有关日志记录的信息。实际上，编织是没有通用的COMEFROM语法实现的。如果您想将AOP添加到不容易支持它的语言中，那么我不确定COMEFROM是否真的会有太大帮助。例如，在C中，要进行编织，您需要从不在GOTO范围内的位置进行COMEFROM，因此这不仅仅是语法糖，以避免使代码混乱，而且还需要所有编织所需的机制，这些机制在C中不存在。 - Steve Jessop

@Jon，这不是我的错，因为你有很有趣的想法 :) - Goran

@Steve 我同意 comefrom != weaving。我之所以提出这个问题，是因为我很惊讶我认为有用的东西被认为是有害的。 - Goran

如果某个东西既有用又有害，那么解决方法就是找到一个更受限制的版本，具有大部分用途但几乎没有危害。因此，结构化编程可以减少对GOTO的有害使用，而连接点可以减少对COMEFROM的有害使用。 - Steve Jessop

Answer 1

对于初学者来说，在任何现代语言中基本上都是无用的，因为你需要：

• 通过行号引用要跳转的位置，而这些是易变的。
• 在代码中放置一个标记或标签，以表示可以从该位置跳转，从而破坏不需要执行此操作的任何可能好处。

另外：

• 使任何形式的调试检查基本上无用。
• 除非保持变量持久化，否则无法真正捕获它跳转的任何上下文，这是在寻求麻烦。

一个更好的想法是：

• 编写钩子API。
• 调用函数！

- thomasfedb

Answer 2

针对您提到的目的，面向切面编程（维基百科）似乎比comefrom更有组织的解决方案。请参见动机和基本概念（同上）底部的示例，了解如何将日志记录添加到单独的文本单元中的方法。

在足够动态的语言中，可以使用“包装”修饰符来处理此类事情：

  def do_something
    ...
  end
  log :do_something, "Something got done"

在这个人为的例子中，log宏会导致do_something方法被替换为一个新方法，该方法首先调用原始的do_something方法，然后将一些内容写入日志。

- Wayne Conrad