This is really about you, your taste in design, and your sensibilities for information hiding.
If you have a global symbol, be it a function name or data item, then that's what it is, a global. Globals, r/w data especially, invite subtle sharing complications, can cause complexity in attempts at modular replacement or in various testing scenarios. Global data works nicely for set once, read mostly scenarios such as the flags package. Even so, it is not so flexible as a contained item with explicit accessors. One approach above is to treat that "var w *window.Window" as private in un-exported scope and then provide a global-visible GetWindow() function that could be called from main or other places. While this is almost literally the same, it is much nicer when you want to change things during testing or in ports where special circumstances are needed. The go compiler's inlining is now good enough that the object style getter setter approach is as fast as global data. (I know there is no big news here but people search these threads and may find value in comprehensive answers) On Fri, Apr 12, 2019 at 10:44 AM alex via golang-nuts < golang-nuts@googlegroups.com> wrote: > > > On Thursday, April 11, 2019 at 6:20:33 AM UTC-4, Dumitru Ungureanu wrote: >> >> It helps a lot! Thanks. >> >> I now have two things to moan about. >> >> If I was to pass c around, I would added it to the params list. If I had >> more others, I'd built a struct. But now, if somehow I lose track of who's >> passing what and where, hard times debugging ahead. Having them declared at >> package level, it seems to cut short the list of things to add, do and >> track. >> > Grouping parameters in a struct (or any kind of aggregate data structure) > should actually make it easier to reason about them, e.g. you are now > reasoning about "configuration" instead of individual configuration > options, making "zoom-in" distinctions only where necessary at the point of > use. > > Passing data around, whether as function arguments or closed-over > variables, increases data locality, reducing the mental scope that you need > to keep active when working on a given piece of code. Having everything you > care about right in front of your eyes makes it easier to keep track of > what's what, compared to having to remember where and why was that > identifier defined. Of course, that is assuming functions are kept > reasonably short. > >> >> > >> If I was to use a init func to initialize w and c, how do I pass them to >> main? Or any initialization, really? >> >> >> I have yet to see a good reason to use init funcs in a main package. Not > saying there can never be, just that I haven't encountered any situation > where the contents of init could not be just added to the beginning of the > main func, without any change in behaviour. At least in your example, you > could do just that and not need to pass anything into main. > > -- > 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. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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.
