2

我正在尝试将局部变量值/名称添加到我的 Swift 日志行中。开箱即用的 Swift 提供了一种很好的方式来装饰日志行#file#function无需显式的努力。我还想更进一步,在日志站点上收集范围内的所有局部变量。

log(
    message: "Things went sideways", 
    // I want to log the following dictionary of local variables without 
    // having to write, maintain or even see the dictionary
    locals: ["foo": foo, "bar": bar, "baz": baz, "buz": buz] 
)

撇开这是否是一个好主意(性能、安全性、隐私、线程安全等)不谈,自动将局部变量字典传递给日志函数的最佳方法是什么?我已经有了一个Mirror基于 - 的解决方案,一旦捕获它们就可以对其进行编码。看来我的选择是:

  1. 建议 Swift 团队添加一个#localVars特殊的文字
    似乎不太可能,他们的盘子里已经有很多了,而且我可能是唯一想要它的人
  2. Fork Swift 并实现我自己的#localVars特殊文字
    跟上对 Swift 的更改可能比手动将局部变量的字典添加到我的日志行中更多的工作
  3. 等待 Swift 编译器插件成为一件事
    可能会很长一段时间,也许永远
  4. 在编译之前构建一个基于 SourceKit 的工具来注入本地 var 映射
    可能是最可行的选择,但也有其挑战。如何编辑转换前的版本但让 Xcode 编译转换后的版本?我可以只转换自上次转换后我编辑的文件吗?Xcode 是否索引我的文件的转换前或转换后版本?
  5. 继续手动
    在数千行日志中编写(并维护和遍历)烦人的局部变量字典。啊
  6. 忘记整个想法
    那将是一个遗憾。在我的事件日志中包含本地人(即使只是在开发中运行时)使这些日志更容易理解

我真的希望有人有一个绝妙的建议,因为上述选项似乎都没有启发性

4

1 回答 1

2

我不确定这个问题是否符合 SO 目的。它是关于编程的,是的,但它是关于某种众所周知的状态(你不能在 Swift 中做到这一点),涵盖很多主题,会导致一个固执己见的答案,你应该做什么,......

我不是在寻找赏金,但很难写出有意义和简短的评论,所以这里是“答案”


建议 Swift 团队添加一个#localVars 特殊文字

似乎不太可能,他们的盘子里已经有很多了,而且我可能是唯一想要的人

除非您将此类问题/讨论移至:

我不确定 SO 上有多少 Swift 工程师。看到了几个,但是我提到的这两个地方肯定是这个问题的更好地方。


Fork Swift 并实现我自己的 #localVars 特殊文字

跟上对 Swift 的更改可能比手动将局部变量的字典添加到我的日志行中工作更多

正如您所说,我希望这比手动构建这些字典要多得多。


等待 Swift 编译器插件成为一件事

可能是很长一段时间,也许是永远

从来没有,可能,不知道。这是泰德的回应

我认为能够促进与 Swift 编译器更紧密集成的工具可能是对项目的一个很好的补充,如果它可以做得好的话。我主要担心的是插件界面的稳定性和安全性。

&

这些都没有设计,但是可以在这里建造很多很棒的东西。如果您有兴趣进一步探索这一点,我认为很自然的一点是首先在 swift-dev 上确定技术方向。一个 swift-evolution 提案似乎是大量讨论和设计的自然产物,但我希望关于 Swift 的这种扩展的讨论可能更多地发生在 swift-devs 上而不是 swift-evolution 因为它是关于内部的编译器和工具,而不是语言。


构建一个基于 SourceKit 的工具,在编译前注入本地 var maps

可能是最可行的选择,但也有其挑战。如何编辑转换前的版本但让 Xcode 编译转换后的版本?我可以只转换自上次转换后我编辑的文件吗?Xcode 是否索引我的文件的转换前或转换后版本?

使用 Xcode 会遇到很多问题。例如 - 我试图将 Swift 格式化程序集成到我的构建过程中并放弃了。Xcode 在修改 Swift 文件时有很多问题。就像 - 你编辑文件,点击构建,Swift 格式化程序重新格式化,Xcode 构建它,你尝试再次编辑文件,如果你想重新加载它,对话框会显示文件已修改,......我也试图在构建开始之前告诉 Xcode 保存所有内容,但没有奏效。它有时有效,有时无效。

这可行吗?也许。我最终向 Apple 报告了它,但还没有反馈/修复。如果你决定走这条路,这只是你将面临的一个例子。


手动继续

在数以千计的日志行中编写(并维护和浏览)令人讨厌的局部变量字典。啊

这是一个问题——应该比较它的工作量。您是否能够以这种方式修改 Swift 编译器,使其花费的时间少于这项手动工作的总时间?未来呢?您愿意花时间合并更改和不断更新吗?特别是当内部结构可以改变时?

因为我也想自动化很多事情,所以我总是问自己——值得吗?


忘记整个想法

那将是一个遗憾。在我的事件日志中包含本地人(即使只是在开发中运行时)使这些日志更容易理解

你真的需要日志中的所有本地人吗?这是个好主意吗?我不知道您的情况或您为什么开始考虑这个问题,但我不是污染日志的忠实粉丝。

我们有一个调试器,我们可以设置断点,执行表达式然后自动继续的断点,您可以将它们存储在项目中,您可以访问frame variable...

你写道——即使只是在开发中运行——为什么不利用我们已经拥有的工具呢?例如,就像提到的断点一样。您是否考虑过安全/隐私方面?当您跳过此条件(仅限开发)时,它也将变为生产,这根本不是一个好主意。为什么您认为 Apple 会在日志中编辑数据(请参阅格式化日志消息)?

这些问题的主要目的是——你真的需要这个吗?还有其他方法吗?这是一个好主意吗?

于 2020-07-03T10:42:47.113 回答