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
