函数参数不是函数颜色

多年来，在网上关于函数颜色的几场辩论中，人们提出了一个明显合理的立场，即函数参数也可以构成颜色。例如，在 Go 中，有一个 context.Context 值，它管理超时、取消以及可以通过各种函数线程化的少量数据。根据设计，它旨在成为通过函数传递的东西，即使接收者不直接使用它而只是传递它。一般来说，一旦一个函数开始使用上下文，您应该将其与所有可能使用它的被调用函数一起线程化。所以，从表面上看，这似乎是一种颜色。一旦您掌握了这个特定的参数，您“必须”使用该参数调用该类型的所有未来函数。扩展这一点，你最终可能会认为所有函数参数都是“颜色”，就像某些函数一样。一个快速但仍然重要的反对意见是，如果是这种情况，我们根本不会谈论这个。如果异步只是由数千种其他颜色组成的令人眼花缭乱的混乱彩虹中的一种“颜色”，那么在编程语言函数发明 50 多年后，这种“颜色”概念就不会被发明出来。异步在某些语言中的工作方式仍然有一些独特之处，值得尝试捕捉和理解。但通过一个例子来深刻理解这一情况是很困难的。下面是我尝试将其变成一个标准而不是单个示例：颜色作为更改依赖关系图形状让我们这样表述问题：假设我必须更改埋在调用堆栈中的某个 4 级函数的属性，无论它是否为“异步”参数，或者其他一些东西，例如“其中是否有 ASM”或函数的任何其他属性。对函数的任何更改都取决于本地语言允许函数具有哪些特征。此更改也可能导致必须更改调用者。可能会出现三种基本情况： 无需对任何调用者进行更改。该更改可能需要更改直接调用者。该更改可能需要更改堆栈中的所有函数。从图形上看，我们有以下内容。对于无颜色、函数参数的情况，“需要更改”关系可能如下所示： 对于有颜色的情况，它如下所示： “颜色”更改与“正常”更改之间的区别在于，在颜色的情况下，对堆栈中底部函数的更改不仅仅影响其父级。它会立即且不可避免地影响调用堆栈中其上方的每个函数，因此，它们都必须对更改做出反应。对于“正常”更改，它仅传播给调用者。然后它可能会链接到它的调用者。如果它一路传播到顶层函数，如图所示，这可能看起来像是没有区别的区别。但关键是该图并没有显示常见情况，而是显示了最坏的情况。在实践中，函数几乎总是在到达调用堆栈顶部之前破坏链。任何函数都可以“捕获”传播的更改并将其封装，以便其上方的函数将不再看到它。您可以通过实际上最终在堆栈上进行线程更改的频率来衡量这一点……好吧……您可以回到我们手工编程的糟糕的旧时代。你知道这是你要做的事情，但它肯定不是你一直在做的事情，也不是你经常做的事情，一直到顶部的主要功能。更改隔离我们人类普遍使用结构化编程，正是因为它能够对大多数功能更改执行此操作，从而将高级功能与需要了解较低功能的每个细节隔离开来。如果最顶层的函数必须知道所有子函数最终需要的“一切”，那会是什么样子呢？对于整个程序中的每个函数参数更改，都会以某种方式强制更改整个调用堆栈？显然这不会发生。它根本不会发生，以至于你甚至可能很难想象我在说什么。例如，就 Go 的上下文而言，我不断提及它不仅是因为 Go 是我的主要编程语言之一，还因为这是不断出现的示例，任何地方的任何函数都可以调用 context.Background() 来获取简并但功能齐全的上下文值。因此，更改为采用上下文的函数仍然可以由任何其他普通函数调用，只需传递 context.Background() 的结果即可。而且这不是一个假设的情况；而是一个假设的情况。这对我来说很常见，当我向一个以前没有的函数添加 context.Context 参数时，在实际代码中准确地执行此操作，以适应测试代码或其他不关心新参数上下文的调用者。所以这种“链表”关系在实践中并不只是容易断链