Re: [go-nuts] flag: bug with shared values?
> 2. if other gophers has ideas of workaround? Use distinct values, but never access them directly. Write setter/getter functions that do the value sharing as you prefer and return the desired result. On Fri, Sep 18, 2020 at 11:30 AM Ian Lance Taylor wrote: > On Fri, Sep 18, 2020 at 12:50 AM Manfred Touron wrote: > > > > 1. if I need to open an issue or not on the go repo, if the fix is not > about code, it can be about doc maybe? > > Documentation fixes are always welcome. You can open an issue or just > send a change. > > > 2. if other gophers has ideas of workaround? > > I don't understand why it is important for these two different flags > to share the same variable. > > Ian > > -- > 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/CAOyqgcU9cMZnf4PaozoBEa4kL7DJgK1PDmnkibDmQ%2BLhbgm%3DJw%40mail.gmail.com > . > -- *Michael T. jonesmichael.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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALoEmQwNNNfMuNQxKHbD3Lo%3Db85Sn8HrNd3YK%3DqMiZGNq8wuMw%40mail.gmail.com.
Re: [go-nuts] flag: bug with shared values?
On Fri, Sep 18, 2020 at 12:50 AM Manfred Touron wrote: > > 1. if I need to open an issue or not on the go repo, if the fix is not about > code, it can be about doc maybe? Documentation fixes are always welcome. You can open an issue or just send a change. > 2. if other gophers has ideas of workaround? I don't understand why it is important for these two different flags to share the same variable. Ian -- 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/CAOyqgcU9cMZnf4PaozoBEa4kL7DJgK1PDmnkibDmQ%2BLhbgm%3DJw%40mail.gmail.com.
Re: [go-nuts] flag: bug with shared values?
There are actually multiple cases of reusing the same XXXVar for the same
variables:
*
https://github.com/golang/go/blob/50bd1c4d4eb4fac8ddeb5f063c099daccfb71b26/src/flag/example_test.go#L29-L30
-> to support shortcuts within the same command
* projects with multiple flag.FlagSet (to manage various subcommands in the
same binary), that shares various common flags, i.e. `--verbose` so they
can globally configure their logger against the same variable
What is unusual and problematic in my case, is that I don't use the same
default value (third param).
Bug or not, I would like to know:
1. if I need to open an issue or not on the go repo, if the fix is not
about code, it can be about doc maybe?
2. if other gophers has ideas of workaround?
Thank you
On Friday, September 18, 2020 at 2:23:04 AM UTC+2 Ian Lance Taylor wrote:
> On Thu, Sep 17, 2020 at 5:04 PM Manfred Touron wrote:
> >
> > I think that I discovered a bug in the stdlib flag package:
> >
> > sharedFlag := "init-value"
> > fooFs := flag.NewFlagSet("foo", flag.ContinueOnError)
> > barFs := flag.NewFlagSet("bar", flag.ContinueOnError)
> > fooFs.StringVar(, "baz", "foo-default", "testing")
> > barFs.StringVar(, "baz", "bar-default", "testing")
> > _ = fooFs.Parse([]string{""}) // no error
> > fmt.Println(*sharedFlag) // bar-default, instead of foo-default
> >
> > To quote @peterbourgon on this issue:
> >
> > > Haha! This is a bug (?) with stdlib flag.FlagSet.
> > > The default value provided to e.g. fs.StringVar isn't kept as metadata
> associated with the flag in the corresponding flagset, but is rather
> assigned to the associated variable. And that assignment happens at
> declaration time, when you call fs.StringVar, and not when you call
> fs.Parse. So the default value you see in any flag set will be the default
> value provided to whichever StringVar declaration happens to occur last —
> in your test, it's this one.
> > > This sucks.
> > > I think the only fix here would be, somehow, avoiding assigning a
> default value in the declaration, and populating it later. Or defining a
> separate e.g. DeferredFlagVar type that encapsulated this behavior? I don't
> know offhand what's best. Ugh.
> >
> > I never contributed to the go repo yet, so I prefer to ask here your
> opinion about this strange behavior, what you suggest in term of fix that
> does not require to touch the stdlib, and if you think that I need to issue
> a bug on the go repo and try to contribute a fix?
>
> What you say is true and I can see how it would be surprising but I
> don't personally consider this to be a bug. It's a design decision.
> Perhaps it should be documented more clearly: don't use the same
> variable for more than one XXXVar calls.
>
> Ian
>
--
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/378e40d2-fb0e-4f8f-a576-839350723b44n%40googlegroups.com.
Re: [go-nuts] flag: bug with shared values?
On Thu, Sep 17, 2020 at 5:04 PM Manfred Touron wrote:
>
> I think that I discovered a bug in the stdlib flag package:
>
> sharedFlag := "init-value"
> fooFs := flag.NewFlagSet("foo", flag.ContinueOnError)
> barFs := flag.NewFlagSet("bar", flag.ContinueOnError)
> fooFs.StringVar(, "baz", "foo-default", "testing")
> barFs.StringVar(, "baz", "bar-default", "testing")
> _ = fooFs.Parse([]string{""}) // no error
> fmt.Println(*sharedFlag) // bar-default, instead of foo-default
>
> To quote @peterbourgon on this issue:
>
> > Haha! This is a bug (?) with stdlib flag.FlagSet.
> > The default value provided to e.g. fs.StringVar isn't kept as metadata
> > associated with the flag in the corresponding flagset, but is rather
> > assigned to the associated variable. And that assignment happens at
> > declaration time, when you call fs.StringVar, and not when you call
> > fs.Parse. So the default value you see in any flag set will be the default
> > value provided to whichever StringVar declaration happens to occur last —
> > in your test, it's this one.
> > This sucks.
> > I think the only fix here would be, somehow, avoiding assigning a default
> > value in the declaration, and populating it later. Or defining a separate
> > e.g. DeferredFlagVar type that encapsulated this behavior? I don't know
> > offhand what's best. Ugh.
>
> I never contributed to the go repo yet, so I prefer to ask here your opinion
> about this strange behavior, what you suggest in term of fix that does not
> require to touch the stdlib, and if you think that I need to issue a bug on
> the go repo and try to contribute a fix?
What you say is true and I can see how it would be surprising but I
don't personally consider this to be a bug. It's a design decision.
Perhaps it should be documented more clearly: don't use the same
variable for more than one XXXVar calls.
Ian
--
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/CAOyqgcW67XjKraQJxuCDsSWMELFkOvdE--VGGDrFH0wDAKAc7A%40mail.gmail.com.
[go-nuts] flag: bug with shared values?
Hi,
I think that I discovered a bug in the stdlib flag package:
sharedFlag := "init-value"
fooFs := flag.NewFlagSet("foo", flag.ContinueOnError)
barFs := flag.NewFlagSet("bar", flag.ContinueOnError)
fooFs.StringVar(, "baz", "foo-default", "testing")
barFs.StringVar(, "baz", "bar-default", "testing")
_ = fooFs.Parse([]string{""}) // no error
fmt.Println(*sharedFlag) // bar-default, instead of foo-default
To quote @peterbourgon on this issue
:
> Haha! This is a bug (?) with stdlib flag.FlagSet.
> The default value provided to e.g. fs.StringVar isn't kept as metadata
associated with the flag in the corresponding flagset, but is rather
assigned to the associated variable. And that assignment happens at
declaration time, when you call fs.StringVar, and not when you call
fs.Parse. So the default value you see in any flag set will be the default
value provided to whichever StringVar declaration happens to occur last —
in your test, it's this one.
> This sucks.
> I think the only fix here would be, somehow, avoiding assigning a default
value in the declaration, and populating it later. Or defining a separate
e.g. DeferredFlagVar type that encapsulated this behavior? I don't know
offhand what's best. Ugh.
I never contributed to the go repo yet, so I prefer to ask here your
opinion about this strange behavior, what you suggest in term of fix that
does not require to touch the stdlib, and if you think that I need to issue
a bug on the go repo and try to contribute a fix?
Thank you,
--
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/5aaa6fd9-4117-4f73-9cc8-b3d29ccf61b5n%40googlegroups.com.
