Thanks! On Sunday, April 14, 2019 at 3:28:59 AM UTC+3, al...@alrux.com wrote: > > 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, itmi...@gmail.com 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
