"Jonathan M Davis" <[email protected]> wrote in message news:[email protected]... > 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.
