On Tue, 04 Oct 2011 20:39:42 +0100, Andrei Alexandrescu
<seewebsiteforem...@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/
