std.getopt suggestion

[Alex Rønne Petersen]

On 28-09-2011 21:44, Jonathan M Davis wrote:
> 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.
>
> - Jonathan M Davis

Sounds good to me.

- Alex