Hacker News new | ask | show | jobs
by weberc2 3280 days ago
This isn't particular to Go, and you should just pass in any variables that you intend to change, rather than depending on a global mutable variable for your state (especially in a concurrency-heavy language like Go).
2 comments

Generally yes. But pi is one of those occasions where it only needs to be a constant somewhere and then forgotten about. The last thing you need is developers accidentally mistyping the value of pi causing the output calculations to be wrong.

If altering the precision of pi is something that matters, then the function should take a parameter for the precision rather than the value of pi.

Pi is not a variable. I was very careful with my wording to say things like "variable", "expect to change", and "mutable state" so my statement would apply generally. :)
Your wording might have been careful but the author did use pi as a variable in his example and discussed wanting the ability to change it. Since you were essentially agreeing with her/his point, it's forgivable if one then assumes you were also agreeing with his example as well. Hence my counterexample (and hence why I opened with "Generally yes" to signify that I don't disagree with your point but the example provided needs tweaking)
I'm not sure I was agreeing with his point, since I only consider one of his configurations 'valid', and even then only insofar as Pi is a variable (which it isn't). My original statement holds generally and specifically--pass in the things you may want to vary; don't depend on global mutable state.
Isn't he just rediscovering the idea of pure functions?

https://en.m.wikipedia.org/wiki/Pure_function

I'm not sure who "he" is, the OP or me? Neither of us are remarking on pure functions, and the OP's suggestions were largely impure (e.g., a global mutable variable to change whenever you might want a different Pi value?). Generally I prefer pure functions, but I'm not religious about it. For example, if the function in question is a method on an object which needs to modify some state in the object, that's all well and good. Just make it explicit that the function has side effects and those side effects are scoped to the object and its methods.