std.getopt suggestion

[Regan Heath]

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.

Lets imagine a possible use-case.  Say you have an application, like a  
development environment.  In it, you have external tools configured, each  
with it's own customisable set of command line options.  Lets say, for a  
certain argument or set of arguments that you pass to the tool, you need  
to behave/react in different ways.  Now, it makes sense to use getopt to  
parse the arguments you're going to pass to the tool, to decide how to  
behave prior to running it.  The tool may be used multiple times in the  
lifetime of the development environment, so getopt is being reused  
repeatedly.  Now, lets suppose each tool uses slightly different command  
line arguments, such that one of more of the existing global variables  
need to be set, for it to parse correctly.  For this to work each use of  
getopt MUST set all 3 globals, or risk one of them being set by another  
use.  Now, lets further suppose that these tools can/are run in parallel.   
With getopt in it's current incarnation it would be impossible to re-use  
it for this.

With a very small change we can retain the current simple interface, but  
also encapsulate the globals and make the whole re-usable, for example...

// ** Current getopt **

dchar optionChar = '-';
string endOfOptions = "--";
dchar assignChar = '=';

void getopt(T...)(ref string[] args, T opts) {}

// ** Proposed getopt **

struct GetOpt
{
   dchar optionChar = '-';
   string endOfOptions = "--";
   dchar assignChar = '=';

   void getopt(T...)(ref string[] args, T opts) {}
}

void getopt(T...)(ref string[] args, T opts)
{
   GetOpt go;
   return go.getOpt(args, opts);
}

Seems like a no-brainer to me.  Unless you want to argue that stacking a  
struct is too inefficient for a once off command line parse, done once at  
the start of a command line application .. I think not.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/