GoKawiilIn several debates online about function colors over the years, people have argued the apparently reasonable position that function arguments can constitute colors as well.
For instance, in Go, there is a context.Context value, which manages timeouts, cancellation, and a small amount of data that can be threaded through various functions. It is, by design, intended to be something passed through functions even if the receiver doesn’t use it directly but only passes it along. Generally, once one function starts using a context, you should thread it along to all called functions that could conceivably have a use for it.
So, superficially, this appears to be a color. Once you have this particular argument in hand, you “have” to call all future functions of that type with that argument.
Extending this out you can end up arguing that all function parameters are “colors”, as some do.
A quick, though still important, objection is to observe that if this was the case, we wouldn’t be talking about this at all. If async was merely one “color” in a dazzling chaotic rainbow of thousands of other colors, this “color” concept wouldn’t have been invented 50+ years after the invention of programming language functions. There is still something distinct about how async works in some languages that is worth trying to capture and understand.
But understanding the situation deeply from one example is difficult. Here is my attempt to turn it into a criterion rather than a single example:
Color As A Change Dependency Graph Shape
Let’s phrase the problem this way:
Suppose I have to change an attribute of some function 4 levels buried in a call stack, be that a parameter that it takes, whether it is “async” or not, or some other thing like “whether or not it has ASM in it” or any other attribute of the function. Any change to the function at all, depending on what characteristics the local language permits functions to have.
This change could result in having to change the callers as well.
... continue reading