While the expected r/w patterns will certainly influence the amount of pain you may feel from using "global state", I would not consider it to be the main deciding factor.
Now, please keep in mind that this whole topic is more a matter of coding style and trade-offs, not necessarily right-or-wrong decisions. It is perfectly normal to see conflicting opinions - use your own judgement in deciding which way seems right for you. And it's also perfectly normal to change your preferences over time - experience is one of those things of which enough is never enough :) With that out of the way, here is my "philosophy": - whenever possible, make each function's "contact surface" explicit, and as small as reasonable. It will lead to lose-coupling that will make your code less brittle: future changes are very unlikely to break things in unexpected places. It will also allow your brain to handle much more complex code bases because it significantly reduces the scope of the cognitive context that *must* reside in your working memory at any given time. - there will be situations where a package-level variable makes sense. You will know when you have such a situation because you will be able to easily articulate why it is preferable - not merely acceptable. - there will also be situations where none of this really matters: the smaller the project, the shorter its expected live, and the fewer people are working on it, the more you can get away with. When you're writing a quick-and-dirty tool to automate your work in a one-off scenario, getting stuff done is all that matters. Then again, the quickest-and-dirtiest tools seem to have a way of sticking around and five years later you're still maintaining and updating that awful code :) The closure solution is only tangentially related to the topic. It is the correct approach for your stated problem, and what it gives you is a way to "adapt" your desired contact surface for your functionality to a given (and different) func signature required by the imported package. It does not matter whether your w var is local or package-level. HTH On Saturday, April 13, 2019 at 4:27:00 PM UTC-4, [email protected] wrote: > > To summarize. > > > - w package-level var is not going to be subject of modification while > being read. No problems to solve, carry on with package-level vars. > - w package-level var is going to be subject of modification while > being read. Problems arise, stop using package-level vars. Solution: pass > it around. Ways: parameters, closures. > > > Please amend. Thanks. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
