std.getopt suggestion

[Nick Sabalausky]

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

I like it. I wonder if having the GetOpt struct's defaults being different 
from getopt() might be confusing. Other than that, I can't think of any 
issues with any of it, unless there was some other aspect of the API we'd 
want to change, too.