On 5/14/16 4:40 PM, Jason White wrote:
> On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu wrote:
>> On 5/13/16 2:27 PM, Russel Winder via Digitalmars-d wrote:
>>> On Thu, 2016-05-12 at 18:25 +0000, Jesse Phillips via Digitalmars-d
>>> wrote:
>>> […]
>>>> unknown flags harder and displaying help challenging. So I'd like
>>>> to see getopt merge with another getopt
>>>
>>> getopt is a 1970s C solution to the problem of command line parsing.
>>> Most programming languages have moved on from getopt and created
>>> language-idiomatic solutions to the problem. Indeed there are other,
>>> better solution in C now as well.
>>
>> What are those and how are they better? -- Andrei
>
> I wrote what I think is an idiomatic-D command line argument parser:
>
>      https://github.com/jasonwhite/darg
>
> You basically define a struct with your options as members. The help
> string is then created at compile time(!). I find this much cleaner than
> std.getopt and the usage/help is prettier.

This is a terrific use of properties and it's a bit of a bummer std.getopt predates them. Thanks for an inspirational package. We should integrate some of these ideas in std.getopt and beyond.

One simple step up for your package would be to do away with the enclosing struct - it can stay optional, but there's no real need for it.


Andrei

On Monday, 2 May 2016 at 12:52:42 UTC, Andrei Alexandrescu wrote:
> This is interesting because it's what std.getopt does but the opposite of what GFLAGS (http://gflags.github.io/gflags/) does. GFLAGS allows any module in a project to define flags. I was thinking of adding GFLAGS-like capabilities to std.getopt but looks like there's no need to... thoughts?
>

LLVM uses a gflags like system. That way, any pass can add its own configuration flag and it all works. On the other hand, it makes it impossible to have the same pass with different config and is a pain in the ass if not used from C/C++ .

If I can see some projects benefiting from a GFlags like approach, I don't think it should be promoted by the standard lib. It only works well if all the code is writen to cooperate in a sensible way. This is good if you have end to end control, but really bad in the general case.

On Sunday, 15 May 2016 at 18:26:21 UTC, Andrei Alexandrescu wrote:
> On 5/14/16 4:40 PM, Jason White wrote:
>> On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu wrote:
>>> On 5/13/16 2:27 PM, Russel Winder via Digitalmars-d wrote:
>>>> On Thu, 2016-05-12 at 18:25 +0000, Jesse Phillips via Digitalmars-d
>>>> wrote:
>>>> […]
>>>>> unknown flags harder and displaying help challenging. So I'd like
>>>>> to see getopt merge with another getopt
>>>>
>>>> getopt is a 1970s C solution to the problem of command line parsing.
>>>> Most programming languages have moved on from getopt and created
>>>> language-idiomatic solutions to the problem. Indeed there are other,
>>>> better solution in C now as well.
>>>
>>> What are those and how are they better? -- Andrei
>>
>> I wrote what I think is an idiomatic-D command line argument parser:
>>
>>      https://github.com/jasonwhite/darg
>>
>> You basically define a struct with your options as members. The help
>> string is then created at compile time(!). I find this much cleaner than
>> std.getopt and the usage/help is prettier.
>
> This is a terrific use of properties and it's a bit of a bummer std.getopt predates them. Thanks for an inspirational package. We should integrate some of these ideas in std.getopt and beyond.
>
> One simple step up for your package would be to do away with the enclosing struct - it can stay optional, but there's no real need for it.

I'm not sure if you saw it, but funopt uses the same basic idea.

When writing ae.utils.funopt, I debated for a bit whether I should use a struct or a function signature as the base for specifying the arguments and their documentation. In the end I went with a function, because it covered all the most important cases, was simpler to use, and closer follows the analogy of invoking a process with some arguments vs. calling a function with some arguments.

On 2016-05-16 01:36, Vladimir Panteleev wrote:

> I'm not sure if you saw it, but funopt uses the same basic idea.
>
> When writing ae.utils.funopt, I debated for a bit whether I should use a
> struct or a function signature as the base for specifying the arguments
> and their documentation. In the end I went with a function, because it
> covered all the most important cases, was simpler to use, and closer
> follows the analogy of invoking a process with some arguments vs.
> calling a function with some arguments.

To me it looks like it can get a bit too verbose for a single function when having more than a couple of flags.

-- 
/Jacob Carlborg

On Sunday, 15 May 2016 at 18:20:54 UTC, Andrei Alexandrescu wrote:
> please take a look

can't get usage text when it very needed
https://issues.dlang.org/show_bug.cgi?id=14525

On Monday, May 02, 2016 08:52:42 Andrei Alexandrescu via Digitalmars-d wrote:
> I found this in https://peter.bourgon.org/go-best-practices-2016/:
>
> "I said it in 2014 but I think it’s important enough to say again: define and parse your flags in func main. Only func main has the right to decide the flags that will be available to the user. If your library code wants to parameterize its behavior, those parameters should be part of type constructors. Moving configuration to package globals has the illusion of convenience, but it’s a false economy: doing so breaks code modularity, makes it more difficult for developers or future maintainers to understand dependency relationships, and makes writing independent, parallelizable tests much more difficult."
>
> This is interesting because it's what std.getopt does but the opposite of what GFLAGS (http://gflags.github.io/gflags/) does. GFLAGS allows any module in a project to define flags. I was thinking of adding GFLAGS-like capabilities to std.getopt but looks like there's no need to... thoughts?

My only issues with std.getopt have been its default settings (in particular that bundling is not turned on by default when in *nix-land at least, bundling is the norm) and the fact that it's a bit hard to handle errors from it. When it throws, you tend to just know that something failed on not what or why, but some improvements have been made to it with regards to printing help and whatnot, and presumably, further improvements could be made.

I've never personally felt the need to add options/flags separately from main, but I've also never dealt with a framework that handled main for me such that I wasn't in control of the code to handle the command-line arguments in the first place. And certainly, my initial reaction is that being able to inject additional command-line argument handling elsewhere in the program is a bad idea and that if there is a framework that handles main for you such that you aren't dealing with the command-line argument handling directly, then it should provide a way for you to hook into the command-line argument handling rather than just letting it be injected willy-nilly. GFLAGS just seems like a bad idea to me. It might make sense in some circumstances, but I'm inclined to think that such circumstances aren't normal enough or common enough to warrant being explicitly supported in the standard library.

- Jonathan M Davis

On Monday, 16 May 2016 at 06:36:03 UTC, Jacob Carlborg wrote:
> On 2016-05-16 01:36, Vladimir Panteleev wrote:
>
>> I'm not sure if you saw it, but funopt uses the same basic idea.
>>
>> When writing ae.utils.funopt, I debated for a bit whether I should use a
>> struct or a function signature as the base for specifying the arguments
>> and their documentation. In the end I went with a function, because it
>> covered all the most important cases, was simpler to use, and closer
>> follows the analogy of invoking a process with some arguments vs.
>> calling a function with some arguments.
>
> To me it looks like it can get a bit too verbose for a single function when having more than a couple of flags.

I'm not sure what you mean, but if you mean what I think you mean, then just write the parameter list with one parameter per line, and it's no different from a struct.

On 2016-05-18 03:15, Vladimir Panteleev wrote:

> I'm not sure what you mean, but if you mean what I think you mean, then
> just write the parameter list with one parameter per line, and it's no
> different from a struct.

I always end up with a struct or class any way to store the arguments, regardless of the framework or language I use.

-- 
/Jacob Carlborg