std.getopt suggestion

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Sep 29 02:21:54 PDT 2011


On 9/29/11 2:11 AM, Christophe wrote:
> Andrei Alexandrescu , dans le message (digitalmars.D:145699), a écrit :
>>> and the aforementioned pull request adds another for an array separator.
>>> Mutable module/global variables are generally considered to be bad design
>>> (though they're sometimes necessary), and I'm very much inclined to have those
>>> variables _not_ be at the module scope like that.
>>
>> Why?
>>
>>> So, my suggestion is that we create a GetOpt struct which contains all of the
>>> options for getopt, and we make getopt a member function of that struct.
>>
>> If the only motivation is that "globals are bad" without further
>> reasoning, I see this as keeping with the letter but not with the spirit
>> of the law.
>
> And why should the spirit of the law not apply to getopt ?
>
> I'll give you further reasoning then:
>
> I want to make a program that reads a file and parse lines with a
> getopt-like syntax. This program uses getopt both to read the program
> argument, and the lines to be read. I decide in a few months to change
> the way the program arguments are parsed. I may inavertedly change the
> parsing options in the file-reading part of my program. Should I have
> forseen this and reset all the getopt options before calling getopt for
> line-reading ?
>
> Making getopt work with a global state means that getopt is only meant
> to be used once at the beginning of the program for reading arguments,
> and that it is not suitable for any other uses, because otherwise, the
> different uses of getopt would interfere with each other. Why should
> such a nice function be reserved for only one usage ?

You can easily build the abstraction you mention on top of std.getopt, 
which means its design is adequate.

Andrei


More information about the Digitalmars-d mailing list