+1<br><br><div class="gmail_quote">On Wed, Sep 28, 2011 at 9:44 PM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Okay. I have a suggestion for an improvement to std.getopt that I think merits<br>
a bit of discussion. There's currently a pull request with some improvements<br>
for getopt which are mostly internal changes rather than API changes (<br>
<a href="https://github.com/D-Programming-Language/phobos/pull/272" target="_blank">https://github.com/D-Programming-Language/phobos/pull/272</a> ), but I think that<br>
there is an API change that we should consider.<br>
<br>
Right now, there are three configuration options which are mutable module-level<br>
variables:<br>
<br>
dchar optionChar = '-';<br>
string endOfOptions = "--";<br>
dchar assignChar = '=';<br>
<br>
and the aforementioned pull request adds another for an array separator.<br>
Mutable module/global variables are generally considered to be bad design<br>
(though they're sometimes necessary), and I'm very much inclined to have those<br>
variables _not_ be at the module scope like that.<br>
<br>
So, my suggestion is that we create a GetOpt struct which contains all of the<br>
options for getopt, and we make getopt a member function of that struct. That<br>
way, if you're doing any configuration to getopt, you create a GetOpt object,<br>
set whatever properties you want to set on it, and call getopt on it - much<br>
cleaner than setting module-level variables. However, because you generally<br>
don't care about setting options on getopt, we then have a getopt function<br>
which is a free function (as we do now) which internally uses GetOpt.init and<br>
calls its getopt. So, it improves the configuration situation but leaves the<br>
usage of std.getopt to be pretty much the same if you don't want to mess with<br>
the default configuration.<br>
<br>
Does anyone think that that's a bad idea for any particular reason?<br>
Personally, I think that it's a significant improvement given that it's getting<br>
rid of the mutable module-level variables and better encapsulating getopt's<br>
functionality, but I think that there's some value in discussing the idea<br>
first.<br>
<br>
Also, it gives us a good opportunity to rename getopt to getOpt (so that it's<br>
properly camelcased per Phobos' naming conventions) as well as change any<br>
defaults which need changing. For instance, the aforementioned pull request<br>
adds a noSpaceOnlyForShortNumericOptions option, which it then recommends<br>
using but doesn't make the default, because it would break code. With this<br>
change, we could make it the default (with the old getopt function still using<br>
the current behavior for as long as its around). Personally, I'd also like to<br>
see bundling be the default, since that's how most command line programs work<br>
(at least on Posix), but regardless, renaming getopt to getOpt gives us a good<br>
opportunity to change some of the defaults if appropriate.<br>
<br>
In any case, the primary question is whether the basic idea of creating a<br>
GetOpt struct for configuring getOpt, making getOpt a member function of it,<br>
and then having a free function getOpt which uses GetOpt.init seems like a<br>
good idea or whether anyone can come up with a good reason why it _wouldn't_<br>
be a good idea.<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font></blockquote></div><br>