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
