std.getopt suggestion

[Jonathan M Davis]

On Thursday, September 29, 2011 13:40 Andrei Alexandrescu wrote:
> On 9/29/11 11:54 AM, Jonathan M Davis wrote:
> > On Thursday, September 29, 2011 11:39 Andrei Alexandrescu wrote:
> >> I don't think it would improve the module design, even without
> >> considering cost of change. It just adds useless clutter.
> > 
> > Well, out of those who have responded in this thread, you're the only one
> > who thinks that. Everyone else has been in favor of either making those
> > config options passable to getopt or in favor of putting getopt on a
> > struct which holds the those config options (with a free function which
> > uses the init value of the struct for the common case).
> 
> Upon further thinking, I'm even less sure than before that that's a good
> idea.
> 
> > And yes, that's an argument by ad populum
> > (or whatever the exact name is), but what's considered "clutter" is
> > subjective.
> 
> Clutter is stuff on top of the baseline that doesn't pull its weight.
> The baseline is:
> 
> "In order to get a command-line options for your program, you must
> import std.getopt, define the variables holding the options, and call a
> function to fill them."

I'm having to wonder if you're misunderstanding what my suggestion is. I'm not 
proposing a major redesign of getopt. The normal use case would be 
_completely_ unchanged. Right now, if you want to alter optionChar, you do

std.getopt.optionChar = '^';
getopt(args, ...);

With my suggestion, you'd do something more like

GetOptConfig config;
config.optionChar = '^';
getopt(args, config, ...);

and you might even just construct the struct and pass it directly, in which 
case, you _save_ a line of code. And that's in the rare case where you 
actually want to mess with those values. In the normal case, it's still

getopt(args, ...);

You only need the struct if you're going to mess with optionChar, 
endOfOptions, or assignChar - which I would expect to be rather rare. The 
_only_ reason that I can think of that someone might want to alter those 
options (assuming that they're just not doing something incredibly abnormal) 
is to try and make the options more Windows-like with / or whatever it is that 
Windows uses instead of - or --. And if _that_ is the use case for altering 
those options, then the struct is an even _better_ idea, because then we could 
provide an instance of GetOptConfig tailored specifically for Windows, where 
the default would still be what we have now, but it would be as simple as

getopt(args, std.getopt.windowsConfig, ...);

and you'd get whatever Windows would normally use. This suggested change does 
_not_ drastically change how getopt works in the normal use case. It simply 
better encapsulates those configuration strings/dchars for getopt and gets rid 
of the mutable global variables (which are generally considered to be bad 
practice). The change for the abnormal use case is minor, and it's arguably 
better, since then the options are encapsulated instead of sitting at module 
scope, and getopt can also be pure, which may or may not be a big deal, but it 
_is_ an improvement.

No, my suggestion is not going to make a huge difference. It's a relatively 
minor improvement. But I do not understand how you can think that it's 
actually better practice to stick mutable variables at module scope instead of 
encapsulating them in a struct for the one function that actually uses them. I 
have never before heard anyone actually try and argue that mutable global 
variables were a _good_ thing. At best, I've heard it argued that they were a 
necessary evil in a particular situation, but never that they were _good_.

Honestly, I would vote against any code being included in Phobos which had any
mutable global variables without a _very_ good reason. And I really don't see
any such reason here.

- Jonathan M Davis