3 ms·

If the object has an API to do functional options, why wouldn't you expect it to be viable to do a scoped override? The API for dynamically changing them alread

If the object has an API to do functional options, why wouldn't you expect it to be viable to do a scoped override? The API for dynamically changing them already implies they are available to be changed frequently. The source of this pattern per the article https://commandcenter.blogspot.com/2014/01/self-referential-functions-and-design.html?m=1 https://commandcenter.blogspot.com/2014/01/self-referential-... The example used is trace verbosity, which is both useful to do a scoped override and cheap to do.

iainmerrick 4y ago
As others have said here, it just feels really un-Go-like (although I'm not a Go user so maybe I don't have the right intuition). Do you really need such a high-level, abstract mechanism just to be able to turn on trace logging? The clunky "big struct of options" approach seems much more idiomatic, and doesn't have any immediately obvious downsides. (That blog post you linked says it's "unsatisfactory"; I guess there's more detail on that elsewhere.) For scoped logging, the obvious approach would just be to add a "setVerbosity" method to your object. You can try to do it in the most general way possible, sure; but that feels similar to building lots of generic data structures and other abstractions, which is something that Go intentionally resisted for a long time (on the basis of keeping things simple and concrete, rather than building ivory towers of abstractions). Anyway, the "Functional Options Are Slow" article reads like a post-hoc justification written by somebody who never liked functional options in the first place anyway -- i.e., the stuff in the final section. The real argument is "I think functional options are a bad idea for style and usability, but if that doesn't convince you, you can also look at the raw performance numbers, and it turns out it's really expensive too." Which I think is a good argument!

iainmerrick 4y ago

As others have said here, it just feels really un-Go-like (although I'm not a Go user so maybe I don't have the right intuition). Do you really need such a high-level, abstract mechanism just to be able to turn on trace logging? The clunky "big struct of options" approach seems much more idiomatic, and doesn't have any immediately obvious downsides. (That blog post you linked says it's "unsatisfactory"; I guess there's more detail on that elsewhere.) For scoped logging, the obvious approach would just be to add a "setVerbosity" method to your object. You can try to do it in the most general way possible, sure; but that feels similar to building lots of generic data structures and other abstractions, which is something that Go intentionally resisted for a long time (on the basis of keeping things simple and concrete, rather than building ivory towers of abstractions). Anyway, the "Functional Options Are Slow" article reads like a post-hoc justification written by somebody who never liked functional options in the first place anyway -- i.e., the stuff in the final section. The real argument is "I think functional options are a bad idea for style and usability, but if that doesn't convince you, you can also look at the raw performance numbers, and it turns out it's really expensive too." Which I think is a good argument!