std.getopt suggestion

Rory McGuire rjmcguire at gmail.com
Thu Sep 29 00:46:12 PDT 2011


+1

On Wed, Sep 28, 2011 at 9:44 PM, Jonathan M Davis <jmdavisProg at gmx.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110929/a36c5d0d/attachment.html>


More information about the Digitalmars-d mailing list