flag: should provide call backs as part of Parse() #8716
Labels
Comments
An example of where this becomes necessary is basically any flag used in testing since it is impossible to interject some kind of setup between flag processing and test start without having to put a sync.Once object at the top of every single test (since who knows which will run given the users command line flags.. etc) So if the intention is that the flag library never be used by anything but main then I guess I can see your argument. Ideally though a library could use flags to set things that impact it at runtime rather than forcing the main() function to cram all of that logic in. For example, setting up proxy settings might be a flag driven function (as well as being exposed via helpers in the library directly). This becomes much more important as abstraction layers get setup. Say you want a flag that says which API endpoint you should target as part of your client library, should the author of the application have to know about the existence of these options and program them into main() even though it doesn't impact their code path in any way? I like go for having a common flag library that unifies the ability for many different things to all act the same and not requires the author of main() to have knowledge of a library used three abstraction layers deep, while still giving the end user to have the ability to change the flag if necessary. It ends up like init(), a way for the caller to set things up prior to things getting real such that blah.Do() doesn't need to be littered around in a hundred places. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by brady:
Ideally I would like to be able to add callbacks to the flags library that get called after all the flags have been parsed, but before flags.Parse() returns. This would give a library which uses flags the ability to check complicated argument's in a way that still returns an "error" in the flag parsing step of the main application. A basic example of the concept: a library accepts two arguments, "-stdout" or "-quiet". Use of both flags is an error to the library. I can either do the argument processing the first time a call into the library is made which cause cause a strange error path to the user ("it ran for 4 minutes they barfed out an argument error!"). Alternatively the main function can be littered with initLibraryX(), initLibraryY() like calls after the flag parsing but before execution. With a callback in flag it would be possible to return a flag error at parse time without intrusion into main by every library included. It also becomes possible to initialize libraries like complex logging from the flags before the first call is made.The text was updated successfully, but these errors were encountered: