std.getopt suggestion

[Steven Schveighoffer]

On Wed, 05 Oct 2011 07:53:25 -0400, Regan Heath <regan at netmail.co.nz>  
wrote:

> On Tue, 04 Oct 2011 20:39:42 +0100, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 10/4/11 12:46 PM, Jacob Carlborg wrote:
>>> On 2011-10-04 17:48, Andrei Alexandrescu wrote:
>>>> On 10/04/11 09:09, Jacob Carlborg wrote:
>>>>> On 2011-10-04 13:21, Regan Heath wrote:
>>>>>> In this particular case, because these std,.getopt options are  
>>>>>> global
>>>>>> variables, building something which uses them, or std.getopt will
>>>>>> introduce side effects to other uses of std.getopt. Meaning the  
>>>>>> current
>>>>>> design makes it impossible to build upon in an orthogonal manner.  
>>>>>> This
>>>>>> is the 'problem' people have with it.
>>>>>>
>>>>>
>>>>> Exactly, yet another reason why std.getopt is badly designed.
>>>>
>>>> Wait, I thought that was the one! Now I wonder what the others were.
>>>>
>>>> Andrei
>>>
>>> Ok, sorry. I meant something like: yet another reason why global values
>>> are bad. And another thing that will hard(er) to do with the current
>>> design of std.getopt.
>>
>> Did it ever prevent you from getting anything done with it?
>
> That's not the question we should be asking.  The question we should be  
> asking is, will anyone ever want to re-use getopts parser for something  
> other than a once off command line parse for a command line  
> application.  The answer is, maybe.  And given that, isn't it better if  
> they can re-use it without running any risk of side-effects etc.

busybox.

(not that I have an opinion here, I've never used getopt before)

-Steve