std.getopt suggestion

[Jacob Carlborg]

On 2011-09-29 22: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."

How can you miss some many times that with the suggestion there will 
still be a free function that you can call if you want to use the 
default settings.


-- 
/Jacob Carlborg