std.getopt suggestion

[Christophe]

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 ?

-- 
Christophe