Debate of the - vs -- flag notation

[nicerobot]

My issue: flag.go doesn't support some common, and in my opinion,
useful notations, yet support is relatively easy to add to flag.go.

My core argument is that support for multiple, duplicate flags as well
as the getopt_long style can be implemented within flag.go while
retaining compatibility. Simply provide a bool in flag.go that will
enable getopt_long compliance. Then, all multi-letter flag names
require --name and -abc is parsed as -a -b -c. Without getopt_long
enabled (the default) it works as it does now.

Additionally, support for duplicate flags, -vvvv, can be implemented
simply by providing flag.Array* functions. Again, remaining compatible
with current usage.


Detailed discussion: re: http://code.google.com/p/go/issues/detail?id=2096

A technique used by rsync to increase verbosity uses multiple -v
flags:

rsync -vvvv

and even this won't work with flag.go:

rsync -v -v -v -v

find also supports multiple, duplicate flags, e.g. -type -o -a -name


It was stated in the issue: There is a real reason: we want to be able
to forget about the historical mistake that is the distinction between
- and --.


I disagree that it is a mistake to use -- for whole-word flags and -
for single character flags. The distinction allows for combining
single-character flags like:

ls -lrt

but any program that uses flag.go will require:

ls -l -r -t

hardly convenient IMO to force this simply to provide single-dash
support for whole-word flags.

In my opinion, the idea of a command-line interface implies users
will, first and formost, type the command. The primary goal of a
command-line interface is therefore to provide short, meaningful,
rememberable commands. Secondarily, support readability in scripts by
supporting whole-word flags. To make it impossible to combine single-
character flags encourages users to create aliases or waste time
typing extra " -" for each flag.

[Brad Fitzpatrick]

I think you're (accidentally?) wandering into a religious discussion.

However this ends:  remember you can always fork the core's flag package and make your own with more or different features.

[Andreas Krennmair]

Have you checked whether other command line parsing libraries for Go
fit your requirements? See http://go-lang.cat-v.org/pure-go-libs
"Command Line UI".

-Andreas

[Russ Cox]

>> [comment that we decided not to follow a common practice]
> [argument for that practice]

[reassurance that we know about that argument
but still decided not to follow said practice]

[signature]

[nicerobot]

Probably but i have never heard of anyone criticizing -- before and a
cursory search didn't reveal an argument against it.

I might end up forking it since i already have a project for command-
line parsing for Objective-C and Java. flag.go might fit nicely into
that project.

[nicerobot]

It's hardly reassuring knowing that a common practice is ignore for no
good reason. To me, it comes across as arrogance.

So many other packages are thorough and well thought-out. They diverge
from the norm in reasonable ways considering the language's features
and capabilities. But flag? It has no reason to do that. It just makes
flag.go seem weak compared to the rest of the packages. Especially
considering i've shown there's really no reason not to support getopt
syntax.

My 2c

[Russ Cox]

> So many other packages are thorough and well thought-out. They diverge
> from the norm in reasonable ways considering the language's features
> and capabilities. But flag? It has no reason to do that. It just makes
> flag.go seem weak compared to the rest of the packages. Especially
> considering i've shown there's really no reason not to support getopt
> syntax.

There is a reason, as I described in the bug.
Flags have proliferated to the point where 'long' names
are the common case, so we might as well drop the
- vs -- distinction and save some neurons.

Every time I have to type

hg mail -m foo --cc bar 123456

[note: - for first, -- for second, or else it fails]
I wish Mercurial were written in Go. :-)

As Brad says, this comes down to a matter of taste
more than anything, and as I said in my original reply,
I do hope someone will write a parser for the flag syntax
you want that actually has a nice, Go-like API,
and make it available via goinstall.

Russ

[Christopher Dunn]

@nicerobot, If it makes you feel any better, I disagree that the distinction was an historical mistake. But as long as the combined flag notation (e.g. "ls -ltr") is not supported, I don't care about "--long-args".

BTW, one reason for double-dash is to make compound words more legible, without having to resort to "--long_args", which requires pressing the <shift> key. That's not a strong argument, but it's every bit as strong as claiming that "--cc" is hard to type.

You're right that "-v -v -v" is not currently supported. Nor is "-list item1 -list item2". At some point a configuration file or environment variables become simpler than command-line arguments.

[Rob 'Commander' Pike]

I'd just like to say that -v 3 is shorter to type than -v -v -v, and that -list item1 -list item2 is supported if you write your own (trivial!) implementation of flag.Value - see the docs.

-rob

[Russ Cox]

> You're right that "-v -v -v" is not currently supported. Nor is "-list item1
> -list item2".

Just to cut this meme off, you can implement
-list item1 -list item2 very easily. See flagVar here:
http://golang.org/src/pkg/flag/flag_test.go#L164

Russ

[Christopher Dunn]

-v 3

  True.

flag.Value

  Thanks. My mistake.

[Christopher Dunn]

Thanks. flag.go is starting to grow on me.

[nicerobot]

Thanks everyone. This clarifies some of the issues for me.

I haven't tried it yet but https://github.com/droundy/goopt claims "An
almost-drop-in replacement for flag."

On Jul 24, 7:31 pm, Christopher Dunn <cdunn2...@gmail.com> wrote:
> @nicerobot, If it makes you feel any better, I disagree that the distinction
> was an historical mistake. But as long as the combined flag notation (e.g.

> "ls -ltr") is *not *supported, I don't care about "--long-args".

[peterGo]

nicerobot,

> A technique used by rsync to increase verbosity uses multiple -v
> flags:
>
> rsync -vvvv
>
> and even this won't work with flag.go:
>
> rsync -v -v -v -v

In Go, implement the verbosity level as an integer flag value from 0
to 9 with a default of zero and -v 5 is moderate verbosity. For
example,

package main

import (
"flag"
"fmt"
)

func main() {
var vp *int = flag.Int("v", 0, "verbosity level: 0 through 9")
flag.Parse()
fmt.Println(*vp)
}

Peter

On Jul 24, 5:37 pm, nicerobot <nicero...@gmail.com> wrote:
> My issue: flag.go doesn't support some common, and in my opinion,> A technique used by rsync to increase verbosity uses multiple -v

[nicerobot]

Thanks Peter. I am familiar with different techniques for designing
flags. I was only use the -vvvv as a short example of using multiple
flags of the same name. There are many, many other examples in which
this occurs and for which such a simple "workaround" isn't possible.
e.g.

find . -type d -o -type l -o -name '*.go'

Well-designed command-line flags can facilitate massive configuration
power without _having_ to resort to external configuration files while
still providing a simple usage for the most common tasks. They can
essentially be a mini domain specific language when the parsing
utility is robust enough to allow it.

[Gustavo Niemeyer]

> find . -type d -o -type l -o -name '*.go'
>
> Well-designed command-line flags can facilitate massive configuration
> power without _having_ to resort to external configuration files while

Rhetorical question: which command line parsing library backs find?

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I never filed a patent.

[André Moraes]

Smart joke to start the day. :-D

--
André Moraes
http://andredevchannel.blogspot.com/

[nicerobot]

While i understand find uses custom parsing, the example i used
wouldn't require customized handling and could easily be handled by
even a simple package like flag.go if it were slightly modified.
Additionally, this was intended as an example of ways to use the same
flag multiple times, not to demonstrate how sophisticated i think
flag.go should be.

This isn't an exercise in discovering which flag parsing package is
used by which applications. It's simply about supporting very common,
standard practices for handling flags, of which multiple is:
http://www.gnu.org/s/gengetopt/gengetopt.html#Multiple-Options .

On Jul 24, 11:08 pm, Gustavo Niemeyer <gust...@niemeyer.net> wrote:
> > find . -type d -o -type l -o -name '*.go'
>
> > Well-designed command-line flags can facilitate massive configuration
> > power without _having_ to resort to external configuration files while
>
> Rhetorical question: which command line parsing library backs find?
>
> --

> Gustavo Niemeyerhttp://niemeyer.nethttp://niemeyer.net/plushttp://niemeyer.net/twitterhttp://niemeyer.net/blog

[Mark Summerfield]

On Mon, 25 Jul 2011 05:55:22 -0700 (PDT)
nicerobot <nice...@gmail.com> wrote:
> While i understand find uses custom parsing, the example i used
> wouldn't require customized handling and could easily be handled by
> even a simple package like flag.go if it were slightly modified.
> Additionally, this was intended as an example of ways to use the same
> flag multiple times, not to demonstrate how sophisticated i think
> flag.go should be.
>
> This isn't an exercise in discovering which flag parsing package is
> used by which applications. It's simply about supporting very common,
> standard practices for handling flags, of which multiple is:
> http://www.gnu.org/s/gengetopt/gengetopt.html#Multiple-Options .

ISTM that quite a few people are not keen on the flag package---I
certainly don't like it---as there are several alternatives available
from the Go dashboard.

I really wish that the Go standard library would adopt an option parsing
package that accepted the same command line arguments as GNU's
getopt_long() function.

I'm not saying this would be "better" than flag since that's a matter of
religious opinion, but it would at least be something that would work in
a standardized way and hold no surprises either for those programming
with it or for those using command line programs that make use of it.

This could be additional to the flag package and would be especially
convenient for those porting command line programs in C, C++, etc., that
use a get getopt_long() function (or similar) to Go.

[snip]

--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3" - ISBN 0321680561
http://www.qtrac.eu/py3book.html

[Christopher Dunn]

>  and would be especially convenient for those porting command line programs in C, C++, etc., that use a get getopt_long() function (or similar) to Go.

That's the most compelling argument I've read. (Pardon the pun.)

[Paul Borman]

The customers of my project will likely balk at flag.go and we will need to adopt one that makes it looks more getopt_long().  It has nothing to do with agreeing with the Go team or not, it is to do with making our customers lives easier.  Why should they be bothered with what language we implement in?

[Russ Cox]

On Mon, Jul 25, 2011 at 16:01, Paul Borman <bor...@google.com> wrote:
> The customers of my project will likely balk at flag.go and we will need to
> adopt one that makes it looks more getopt_long().  It has nothing to do with
> agreeing with the Go team or not, it is to do with making our customers
> lives easier.  Why should they be bothered with what language we implement
> in?

Then import a different flag package. It's pretty easy.

Russ