why not flag.Parse() in init()?

[Dan Kortschak]

There has often been an exhortation not to flag.Parse() in an init
function. I can see why this is true in the case of the example provided
in the flag package example because there are are a number of init
functions that are defined that call flag definition functions so you
may not get the Parse() call after all the definitions.

But if all the definitions and the Parser() call are within the same
init and/or the flag definitions are made using the non-Var form,
defining package level variables, I can't see how this would be
incorrect. Am I missing something?

thanks
Dan

[Ian Lance Taylor]

If you do it in the main package you are probably OK.

But don't do it in some other package, that will just be trouble over time.

Ian

[Dan Kortschak]

On Tue, 2013-04-23 at 21:06 -0700, Ian Lance Taylor wrote:
> If you do it in the main package you are probably OK.
>
> But don't do it in some other package, that will just be trouble over
> time.

OK, I was interpreting it too strongly then. Yes, that's a clear case -
I only use Parse in main packages.

thanks

[Andreas Krennmair]

One general reason against putting too much code into the init() function is that init(), unlike main(), is called when you run unit tests using "go test" for your package.

Regards,

Andreas

Dan

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dan Kortschak]

So again, if you have most of your logic factored out into other
packages and the main packing is just the final layer interfacing to the
CLI, there is no real reason against it.

[Ingo Oeser]

Hi Dan,

You can define almost all of the flag logic outside of main.main()

Packages like github.com/jessevdk/go-flags even combine various methods 

to configure a system (part).

If you have lots of code depending on configurable values,

you could build some kind of registry of hooks you fill on init() and call that in main.main()

directly after flags.Parse(). 

The package listed above cans also help you with that, as it supports callbacks per option.

Just some ideas to toss around :-)

Best Regards

Ingo

[Dan Kortschak]

Yeah, I've never had any problems with a large variety of approaches. I
variably define flags as top level package vars, in init functions and
in main functions. I variably call Parse in init and main functions.

This was really just a curiosity because of some fairly vehement claims
that Parse should not be called from init functions without
qualification. For my use (I never - except in testing code - define
flags that are not in a main package) none of these cause problems, so I
wanted to understand the issue. Ian's answer covered it.

thanks
Dan