FAQ
Hi

sflag is the only known flag package variant, at the time of writing, that
is 100% DRY, free of fugly pointer syntax and uses clean struct syntax.
The implementation makes use of reflection and struct tags.

Source code : https://github.com/teamldcs/sflag
Documentation with example at http://godoc.org/github.com/teamldcs/sflag

Looking forward to comments/patches.

Thanks,
LDCS Team
https://github.com/teamldcs

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

Search Discussions

  • Egon at Dec 2, 2014 at 7:03 am
    That's actually the first flag package (other than std) I like.

    Anyways, make Getter/Setter interfaces work to allows custom types as
    flags http://golang.org/pkg/flag/#Getter

    Using pointer to a string/num is useful for optional arguments. i.e.
    Specifying an empty flag is not always the same as not specifying a flag.

    Create an additional "Parse" that takes its arguments from []string instead
    of os.Args.

    https://github.com/teamldcs/sflag/blob/master/sflag.go#L74
    switch on the Kind() not String() http://golang.org/pkg/reflect/#Kind
    Or alternatively use a type switch on the actual value.

    + Egon
    On Tuesday, 2 December 2014 03:46:16 UTC+2, te...@ldcs.co.in wrote:

    Hi

    sflag is the only known flag package variant, at the time of writing, that
    is 100% DRY, free of fugly pointer syntax and uses clean struct syntax.
    The implementation makes use of reflection and struct tags.

    Source code : https://github.com/teamldcs/sflag
    Documentation with example at http://godoc.org/github.com/teamldcs/sflag

    Looking forward to comments/patches.

    Thanks,
    LDCS Team
    https://github.com/teamldcs
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Craig-Wood at Dec 2, 2014 at 8:13 am

    On 02/12/14 01:46, team@ldcs.co.in wrote:
    sflag is the only known flag package variant, at the time of writing,
    that is 100% DRY, free of fugly pointer syntax and uses clean struct
    syntax.
    The implementation makes use of reflection and struct tags.

    Source code : https://github.com/teamldcs/sflag
    Documentation with example at http://godoc.org/github.com/teamldcs/sflag
    Does indeed look very neat.

    I saw another flag parser which uses struct tags but I can't find it any
    more!

    Using this scheme takes away the advantage of the standard package of
    being able to define flags anywhere - right next to where they are
    needed for instance - which is a feature that I really like.

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chris Hines at Dec 2, 2014 at 4:08 pm
    It reminds me of https://github.com/cespare/flagconf

    Which also provides support for reading configuration from TOML files and
    allowing the command line to override those values.
    On Monday, December 1, 2014 8:46:16 PM UTC-5, te...@ldcs.co.in wrote:

    Hi

    sflag is the only known flag package variant, at the time of writing, that
    is 100% DRY, free of fugly pointer syntax and uses clean struct syntax.
    The implementation makes use of reflection and struct tags.

    Source code : https://github.com/teamldcs/sflag
    Documentation with example at http://godoc.org/github.com/teamldcs/sflag

    Looking forward to comments/patches.

    Thanks,
    LDCS Team
    https://github.com/teamldcs
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Markus Zimmermann at Dec 2, 2014 at 4:59 pm
    My comments:
    - I had a hard time reading your documentation. I thing you should be more
    verbose and explain every feature one at a time and be more precise in your
    big example e.g. what is an description and what is a default value, why
    does the first char of the tag matter, ...
    - Do not panic, return errors
    - Do not ignore errors, handle them e.g. for ParseInt
    - Have a look at unicode.IsLetter
    - Rename your variables according to their task e.g. "part0" and "part1",
    pp, vv and why "ii" instead of "i"? Short names are OK when they are
    obvious. Have a look at http://talks.golang.org/2014/names.slide
    - Do not put everything in one function use a new one for each distinct
    task e.g. you can do the for-loop block in its own function
    - The usage concatenations are not DRY. Since you know the type you can
    build the usage string once for all flags and save it in a variable.
    - Write more tests and also test each feature on its own. One big test is
    normally not a good idea.

    Also since I am with the go-flags crowd (yes, I get excited when I see a
    new flags package) have a look for some ideas
    https://github.com/jessevdk/go-flags (which also seems 100% DRY to me btw.)

    @nick: One package that does the same thing, with lots of additional
    features like auto-completion, is the mentioned go-flags which addresses
    your use-case with AddGroup and AddCommand. Create an issue in the tracker
    or mail me if you want to know more.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tech Team at Dec 2, 2014 at 11:47 pm
    - Getter/Setter - our workflow does not involve this, but happy to
    entertain pullreq.
       - Pointer vals - really averse to pointer syntax, is there a way to
    achieve this without forcing pointer syntax on ALL usage?
       - ParseSlice - good idea, will go on our todo
       - Kind() - good idea, will go on our todo

       - inability to declare near use - matter of taste, we approve golang's
    decision to declare func's args in one location at entry, and sflag is
    nothing but func main's arglist.

       - comparison to "flagconf" - Thanks for pointing out. It is similar in
    making use of struct tags and reflection, but our needs are different.
    We wrote sflag for extreme brevity, to reduce the linecount threshold below
    which our team reaches for Bash instead of Golang. For larger programs
    requiring configuration, we prefer a different config file format
    (hierarchical, sparse-tabular, at some point parsers for Golang and C++
    will be appear on our github) and those invocations tend to be too
    dangerous to reconfigure at the commandline, and finally, `json` is not
    permitted on corporate premises.

       - documentation improvements - will do
       - panic vs error - internal corporate policy is to panic asap on
    incorrect commandline args. however, have added ParseError() to the todo
    to suit this taste
       - ParseInt error - internal corporate policy requires us to ignore error
    returns on a shortlist of pedantic golang funcs, until such time as golang
    vN, N > 1, fails to compile on golang users current ability to opinionate
    differently to the golang authors (unquestioned right to) opinions.
       - unicode.isLetter - internal corporate policy disallows acknowledgement
    of unicode's existence.
       - ii vs i - internal corporate style guide disallows ungreppable
    single-char variable names as well as single-char programming languages, go
    made the cut. iteration variables must be ii, jj, etc. "part0" - please
    suggest more appropriate name. w? not sure how that snuck in, please
    point out line number, must remove.
       - exploding single func - no objections, please send pull req
       - usage concatenation not DRY - not sure what was meant exactly - DRYness
    is required for package callers, not for sflag implementation
       - test functions - corporate policy requires test functions - however
    team threatened to quit and mgmt gave in. We welcome pull requests with
    test functions...
       - go-flags - very impressive package. reasons we continued with
    s(imple)flag (1) announcement on gonuts predated our adoption of golang (2)
    with great power comes ability for junior team members to code with great
    complexity (3) usage not DRY enough - too much of "short", "long" in the
    github example, way beyond the attention span of senior citizens on the
    team (4) corporate policy disallows closures, dates back to functional
    language course taken 30 years ago, and CTO was not clever enough to
    determine, within the hour allotted, whether go-flags package permits
    closures.
    On Tue, Dec 2, 2014 at 10:29 PM, Markus Zimmermann wrote:

    My comments:
    - I had a hard time reading your documentation. I thing you should be more
    verbose and explain every feature one at a time and be more precise in your
    big example e.g. what is an description and what is a default value, why
    does the first char of the tag matter, ...
    - Do not panic, return errors
    - Do not ignore errors, handle them e.g. for ParseInt
    - Have a look at unicode.IsLetter
    - Rename your variables according to their task e.g. "part0" and "part1",
    pp, vv and why "ii" instead of "i"? Short names are OK when they are
    obvious. Have a look at http://talks.golang.org/2014/names.slide
    - Do not put everything in one function use a new one for each distinct
    task e.g. you can do the for-loop block in its own function
    - The usage concatenations are not DRY. Since you know the type you can
    build the usage string once for all flags and save it in a variable.
    - Write more tests and also test each feature on its own. One big test is
    normally not a good idea.

    Also since I am with the go-flags crowd (yes, I get excited when I see a
    new flags package) have a look for some ideas
    https://github.com/jessevdk/go-flags (which also seems 100% DRY to me
    btw.)

    @nick: One package that does the same thing, with lots of additional
    features like auto-completion, is the mentioned go-flags which addresses
    your use-case with AddGroup and AddCommand. Create an issue in the tracker
    or mail me if you want to know more.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Arne Hormann at Dec 3, 2014 at 7:50 am
    I presented a somewhat similar library I wrote as a prototype at a Go user
    group yesterday
    (http://www.meetup.com/Frankfurt-Gophers-Meetup/events/213104132/).
    Mine is from May, I'll finish it over the holidays. The api will change
    considerably, though.

    Usage example: http://play.golang.org/p/WUEdZwmfjA
    Api docs for protoype
    version: http://godoc.org/github.com/arnehormann/goof/envflag

    Cheers,
    Arne

    Am Mittwoch, 3. Dezember 2014 00:47:59 UTC+1 schrieb Tech Team:
    - Getter/Setter - our workflow does not involve this, but happy to
    entertain pullreq.
    - Pointer vals - really averse to pointer syntax, is there a way to
    achieve this without forcing pointer syntax on ALL usage?
    - ParseSlice - good idea, will go on our todo
    - Kind() - good idea, will go on our todo

    - inability to declare near use - matter of taste, we approve golang's
    decision to declare func's args in one location at entry, and sflag is
    nothing but func main's arglist.

    - comparison to "flagconf" - Thanks for pointing out. It is similar in
    making use of struct tags and reflection, but our needs are different.
    We wrote sflag for extreme brevity, to reduce the linecount threshold below
    which our team reaches for Bash instead of Golang. For larger programs
    requiring configuration, we prefer a different config file format
    (hierarchical, sparse-tabular, at some point parsers for Golang and C++
    will be appear on our github) and those invocations tend to be too
    dangerous to reconfigure at the commandline, and finally, `json` is not
    permitted on corporate premises.

    - documentation improvements - will do
    - panic vs error - internal corporate policy is to panic asap on
    incorrect commandline args. however, have added ParseError() to the todo
    to suit this taste
    - ParseInt error - internal corporate policy requires us to ignore error
    returns on a shortlist of pedantic golang funcs, until such time as golang
    vN, N > 1, fails to compile on golang users current ability to opinionate
    differently to the golang authors (unquestioned right to) opinions.
    - unicode.isLetter - internal corporate policy disallows acknowledgement
    of unicode's existence.
    - ii vs i - internal corporate style guide disallows ungreppable
    single-char variable names as well as single-char programming languages, go
    made the cut. iteration variables must be ii, jj, etc. "part0" - please
    suggest more appropriate name. w? not sure how that snuck in, please
    point out line number, must remove.
    - exploding single func - no objections, please send pull req
    - usage concatenation not DRY - not sure what was meant exactly -
    DRYness is required for package callers, not for sflag implementation
    - test functions - corporate policy requires test functions - however
    team threatened to quit and mgmt gave in. We welcome pull requests with
    test functions...
    - go-flags - very impressive package. reasons we continued with
    s(imple)flag (1) announcement on gonuts predated our adoption of golang (2)
    with great power comes ability for junior team members to code with great
    complexity (3) usage not DRY enough - too much of "short", "long" in the
    github example, way beyond the attention span of senior citizens on the
    team (4) corporate policy disallows closures, dates back to functional
    language course taken 30 years ago, and CTO was not clever enough to
    determine, within the hour allotted, whether go-flags package permits
    closures.

    On Tue, Dec 2, 2014 at 10:29 PM, Markus Zimmermann <zim...@gmail.com
    <javascript:>> wrote:
    My comments:
    - I had a hard time reading your documentation. I thing you should be
    more verbose and explain every feature one at a time and be more precise in
    your big example e.g. what is an description and what is a default value,
    why does the first char of the tag matter, ...
    - Do not panic, return errors
    - Do not ignore errors, handle them e.g. for ParseInt
    - Have a look at unicode.IsLetter
    - Rename your variables according to their task e.g. "part0" and
    "part1", pp, vv and why "ii" instead of "i"? Short names are OK when they
    are obvious. Have a look at http://talks.golang.org/2014/names.slide
    - Do not put everything in one function use a new one for each distinct
    task e.g. you can do the for-loop block in its own function
    - The usage concatenations are not DRY. Since you know the type you can
    build the usage string once for all flags and save it in a variable.
    - Write more tests and also test each feature on its own. One big test is
    normally not a good idea.

    Also since I am with the go-flags crowd (yes, I get excited when I see a
    new flags package) have a look for some ideas
    https://github.com/jessevdk/go-flags (which also seems 100% DRY to me
    btw.)

    @nick: One package that does the same thing, with lots of additional
    features like auto-completion, is the mentioned go-flags which addresses
    your use-case with AddGroup and AddCommand. Create an issue in the tracker
    or mail me if you want to know more.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Dec 2, 2014 at 11:02 pm

    On 2 Dec 2014 14:33, wrote:
    sflag is the only known flag package variant, at the time of writing,
    that is 100% DRY, free of fugly pointer syntax and uses clean struct syntax.

    Please follow the struct tag convention:
    http://golang.org/pkg/reflect/#StructTag

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger peppe at Dec 3, 2014 at 8:18 am
    There is no need to use unsafe in a package like this. Please don't.
    (You can use a type switch on vv.Addr().Interface())

    It seems wrong to require all flags to begin with a capital letter.
    It also seems wrong to panic if any argument is the word "true" or
    "false" when there's a bool flag. Your example panics on this
    input:
         ./tst -Age 19 my love is true

    I like the approach of layering on top of the flags package.
    You could provide for more advanced usage by providing
    the capability to set flags on an existing flags.FlagSet.

    e.g.

        func AddFlags(fs *flags.FlagSet, value interface{})

    On 2 December 2014 at 01:46, wrote:
    Hi

    sflag is the only known flag package variant, at the time of writing, that
    is 100% DRY, free of fugly pointer syntax and uses clean struct syntax.
    The implementation makes use of reflection and struct tags.

    Source code : https://github.com/teamldcs/sflag
    Documentation with example at http://godoc.org/github.com/teamldcs/sflag

    Looking forward to comments/patches.

    Thanks,
    LDCS Team
    https://github.com/teamldcs

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Team LDCS at Dec 5, 2014 at 12:25 am
    Please note that the sflag repo has changed location to
    https://github.com/LDCS/sflag
    and the documention is now at http://godoc.org/github.com/LDCS/sflag

    +egon
       - pointer flags feature request - added in latest checkin, nil pointers
    will be set from cmdline (no defaults obviously), non-nil pointers ignored

    +markus
        - poor feature coverage in documentation - improved in latest checkin
    thru better package and func comments

    +nigel
        - struct tag convention - sorry cannot change this because the
    conventional style hurts the eye, hence is counter to sflag's raison d'etre.

    +arne
        - envflag - seems more powerful, but not DRY - each arg appears twice
    (in definition and setting default)

    +rog
       - "unsafe" unnecessary - removed in latest checkin
       - wrong to require first letter capital - Not true, it is idiomatic if
    you view commandline args as exported members of package main
       - wrong to panic on true/false - It is a limitation of relying on std
    flag package for parsing, that sets boolflag true on presence alone,
    whereas we prefer explicitness.
       - AddFlags - beyond our need - current sflag has served unchanged for 18
    months internally - still, send pullreq if you wish

    Thanks,
    Team LDCS
    On Wednesday, December 3, 2014 1:49:08 PM UTC+5:30, rog wrote:

    There is no need to use unsafe in a package like this. Please don't.
    (You can use a type switch on vv.Addr().Interface())

    It seems wrong to require all flags to begin with a capital letter.
    It also seems wrong to panic if any argument is the word "true" or
    "false" when there's a bool flag. Your example panics on this
    input:
    ./tst -Age 19 my love is true

    I like the approach of layering on top of the flags package.
    You could provide for more advanced usage by providing
    the capability to set flags on an existing flags.FlagSet.

    e.g.

    func AddFlags(fs *flags.FlagSet, value interface{})

    On 2 December 2014 at 01:46, <te...@ldcs.co.in <javascript:>> wrote:
    Hi

    sflag is the only known flag package variant, at the time of writing, that
    is 100% DRY, free of fugly pointer syntax and uses clean struct syntax.
    The implementation makes use of reflection and struct tags.

    Source code : https://github.com/teamldcs/sflag
    Documentation with example at http://godoc.org/github.com/teamldcs/sflag

    Looking forward to comments/patches.

    Thanks,
    LDCS Team
    https://github.com/teamldcs

    --
    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 <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Konstantin Khomoutov at Dec 5, 2014 at 12:08 pm

    On Thu, 4 Dec 2014 16:25:20 -0800 (PST) Team LDCS wrote: [...]
    - wrong to require first letter capital - Not true, it is idiomatic
    if you view commandline args as exported members of package main
    [...]

    Well, the problem is that this approach does not follow any of the
    established practices of using command-line arguments (may be except
    some abominations found in obscure corners of Windows). Users will
    have to forfeit their finger memory to use binaries using your package.
    Of course, this may be okay if the merit this approach provides
    outweights the inconvenience, but I think this is not the case: why
    do you think the users of the program have any knowledge about the Go's
    conventions of exporting symbols from packages? You know this, yes,
    but an average user or even a devops team member? Come on...

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Team LDCS at Dec 7, 2014 at 5:39 am
    +egon
       []string instead of os.Args - implemented in latest checkin - Args member
    overrides os.Args[1:] if non-nil

    +nick
       sflag is not pioneering - truly! In fact "flagtag" published mid-year
    uses near-identical ideas. Doco fixed in latest checkin.

    +markus
       bad doco - latest checkin has test/examples for individual features, in
    addition to kitchen sink example

    +rog
       cannot handle lowcase args - fixed in latest checkin, member Foo_ will
    set from --foo

    +konstantin
       sflag ~ Windows - Now that's a low blow! We succumb, lowcase is
    implemented. (For next time - may we recommend
    https://freedomsponsors.org/ as the honorable way)

    On Friday, December 5, 2014 5:39:15 PM UTC+5:30, Konstantin Khomoutov wrote:

    On Thu, 4 Dec 2014 16:25:20 -0800 (PST)
    Team LDCS <te...@ldcs.co.in <javascript:>> wrote:

    [...]
    - wrong to require first letter capital - Not true, it is idiomatic
    if you view commandline args as exported members of package main
    [...]

    Well, the problem is that this approach does not follow any of the
    established practices of using command-line arguments (may be except
    some abominations found in obscure corners of Windows). Users will
    have to forfeit their finger memory to use binaries using your package.
    Of course, this may be okay if the merit this approach provides
    outweights the inconvenience, but I think this is not the case: why
    do you think the users of the program have any knowledge about the Go's
    conventions of exporting symbols from packages? You know this, yes,
    but an average user or even a devops team member? Come on...
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger peppe at Dec 8, 2014 at 9:55 am

    On 5 December 2014 at 00:25, Team LDCS wrote:
    - wrong to panic on true/false - It is a limitation of relying on std flag
    package for parsing, that sets boolflag true on presence alone, whereas we
    prefer explicitness.
    Suppose I implement some program that processes files, using
    sflag to parse its command line flags. Then I happen to run it
    in /bin:

         $ cd /bin
         $ myprog *
         panic: Golang flag package requires "--Foo=bar" instead of "--Foo
    bar" syntax for bool args

         goroutine go: exit 2
         1 [running]:
         github.com/LDCS/sflag.Parse(0x4ac7c0, 0x583960)
         /home/rog/src/go/src/github.com/LDCS/sflag/sflag.go:196

    Oops. This is very wrong behaviour, I'm afraid. It's not great to just
    prevent programs from having any argument which is "true" or "false".

    BTW, your implementation is doing quite a bit more work than it needs
    to. You don't need to use reflect that much. For the record, you can
    compare reflect types with "==" - there's no need to use String.

    Here's a suggestion for a somewhat simplified version of your code:
    http://play.golang.org/p/kEVs1ZapCx

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 2, '14 at 3:33a
activeDec 8, '14 at 9:55a
posts13
users9
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase