Go doesn't have file scoped variables, only global variables and local
variables declared in functions, so your "file" scope variables are global
to their package.
Global variables aren't inherently bad, that's a bit of voodoo that some
ideological languages introduced, and people believe without question.
Now, as for your particular example, I've handled this in a different way
in my own code. Each of your packages can have a "RegisterFlags()" function
which registers its own command line flags, and returns a struct containing
the flags. You can implement another function called
"InitFromFlags(flagStruct...)". This way, there's no global state, and
package initialization is still decoupled from flags.
On Fri, Feb 17, 2023 at 9:18 PM Pat Farrell <pat22...@gmail.com> wrote:
> I'm still struggling with how to setup my access.
> I'm building a library, say tagtool and it has a nice clean
> subdirectory with the files
> that make up the go package, each with
>
> package tagtool
>
> And I have a subdirectory called "cmd" that contains a near trivial main.go
> that calls the various tagtool.Mumble() func.
> So far, so good.
>
> But I've been using file/package level vars. This is clearly a bad thing.
> So I'm trying to bundle all the various vars into a struct, and
> I'll have my main.go call a
>
> func AllocateData() *GlobalVars {
> rval := new(GlobalVars)
> //.. do other init stuff
> return rval
> }
>
> This way we have the main holding the storage for what had been
> file/package level
> vars.
>
> Which is a good start. It works great if I capitalize all the variables.
> But I really don't want to make all of the variables in the struct be part
> of my public API. They are all implementation details. I need to be able to
> initialize various variables in the GlobalVars struct from my 'main.go'
>
> Right now, its mostly flag variables that I need. Stuff like
> flag.BoolVar(&flags.Debug, "de", false, "debug on")
>
> The main.go doesn't really care about the values once the flag package has
> set them from the shell arguments, it just wants the tagtool
>
> Is there a "friend" declaration or import that lets the "package main"
> look into
> the package tagtool?
>
> Thanks
> Pat
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d64ccb62-9134-4c66-8fb3-6ce1ffe19871n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/d64ccb62-9134-4c66-8fb3-6ce1ffe19871n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LsSpCCFs9i_8YEwmUBFH-2p_FZRYAWQ3ivuoBabLyy1Lw%40mail.gmail.com.
