Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flag: add and support implicit boolFlag interface #4262

Closed
gopherbot opened this issue Oct 19, 2012 · 7 comments
Closed

flag: add and support implicit boolFlag interface #4262

gopherbot opened this issue Oct 19, 2012 · 7 comments
Labels
FrozenDueToAge Suggested Issues that may be good for new contributors looking for work to do.
Milestone

Comments

@gopherbot
Copy link

by brady:

In the flag module the following code:

if fv, ok := flag.Value.(*boolValue); ok { // special case: doesn't need an arg
  if has_value {
    if err := fv.Set(value); err != nil {
      return false, f.failf("invalid boolean value %q for  -%s: %v", value, name, err)
    }
  } else {
    fv.Set("true")
}

Ensures that its completely impossible to implement any kind of call back when a flag is
provided without value. Would it be possible to define an interface that has say a
"Default()" function, and use that here to cast/call so that its possible for
a third party flag to have access to this special case?

Examples of implementations where this is useful:

# Count the number of times -v is passed.
./count_dash_v -v -v -v -v

# Provide very specific help (and then exit)
./special_help --help_about_some_topic

etc.

If desired I can provide a patch as well, I figure this would be trivial to implement
outside of the inevitable naming war. =)
@robpike
Copy link
Contributor

robpike commented Oct 19, 2012

Comment 1:

I'm not sure it's valuable enough to bother. The flag package is intricate enough
already and without careful guarding flag packages become overfertilized. However, if (I
stress - if) one were to do this, a simpler, API-changeless way to do it would be to
change the if statement to see if the flag is some kind of boolean, as opposed to
explicitly boolValue. Then the client could use the existing interfaces to provide the
desired behavior.
reflect.ValueOf(flag.Value).Elem().Kind() == reflect.Bool

Status changed to Thinking.

@rsc
Copy link
Contributor

rsc commented Oct 21, 2012

Comment 3:

If we were going to do this, I would not do it by tying the value to
the underlying type. It should be something declared explicitly by the
flag. For example, a flag implementation could optionally satisfy
type BoolFlag interface {
    IsBoolFlag() bool
}

@rsc
Copy link
Contributor

rsc commented Dec 9, 2012

Comment 4:

1. Add interface from comment #3 as boolFlag (unexported).
2. Add IsBoolFlag method to boolVar implementation.
3. Document in flag.Value comment:
//
// If a Value has an IsBoolFlag() bool method returning true,
// the command-line parser makes -name equivalent to -name=true
// rather than using the next command-line argument.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 5:

Labels changed: added size-m.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 6:

Labels changed: added suggested.

@gopherbot
Copy link
Author

Comment 7 by rickarnoldjr:

Fixed by https://golang.org/cl/6944064

@rsc
Copy link
Contributor

rsc commented Dec 22, 2012

Comment 8:

This issue was closed by revision a6d986b.

Status changed to Fixed.

@gopherbot gopherbot added fixed Suggested Issues that may be good for new contributors looking for work to do. labels Dec 22, 2012
@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge Suggested Issues that may be good for new contributors looking for work to do.
Projects
None yet
Development

No branches or pull requests

3 participants