std.getopt suggestion

[Andrei Alexandrescu]

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."

> Yes, the improvement would be relatively minor, but so's the cost
> of the change, and while it doesn't necessarily show that you're wrong when no
> one seems to agree with you, it does at least say something when no one agrees
> with you.

A good argument would be a whole lot better. My perception is, again, 
that we're not looking at a small improvement. It's a step back.


Andrei