std.getopt suggestion

[Jacob Carlborg]

On 2011-09-30 08:51, Andrei Alexandrescu wrote:
> On 9/29/11 11:35 PM, Jacob Carlborg wrote:
>> 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.
>
> If anyone missed anything, it's you who missed my not missing it :o).
>
> Andrei

Since you're repeating the same argument over and over it looks like you 
missed it.

-- 
/Jacob Carlborg