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
