std.getopt suggestion

[Jonathan M Davis]

On Thursday, September 29, 2011 08:41 Andrei Alexandrescu wrote:
> The proposed change adds net negative value. It forces people to create
> an object in order to call a simple function, for the vague benefit of
> tenuous corner cases.

I specifically suggested that there still be a free getopt function which 
wraps the call to GetOpt.init. So, for most people, there would be no cost to 
having a struct to hold the configuration options. Yes, if I were suggesting 
that everyone be forced to create a an object to call getopt, that would be 
definite net negative change, making the average user of std.getopt pay for 
improving a rare use case. But I'm not suggesting that. And if people think 
that it's better to have a GetOpt struct (or whatever you want to call it; the 
name isn't all that important to me - GetOptConfig?) which is passed to 
getOpt, then that's fine too. It just seems simpler to me to make getOpt a 
member function, so I suggested that. The main point was that it's more poorly 
encapsulated to have the mutable variables free in the module, it breaks 
purity, and while it might work fine for std.getopt since it's really only 
doing one thing, it's still generally bad design to put mutable variables at 
module scope, so it looks bad to a lot of programmers, and there's no real 
cost that I see to having them in a struct.

So, if the issue is that getOpt is a member function on a struct rather than 
taking the struct, then we can have it take the struct. And on the whole, I do 
think that std.getopt works great and has a solid design. But I don't 
understand why you would ever have mutable globals. They don't really buy you 
anything. With the struct, worst case, you create it and pass it to the getOpt 
call, and it adds one line of code for constructing the type before setting 
the value.

GetOptConfig config;
config.endOfOptions = "@";
getOpt(args, config, ...);

And if you construct it and pass it directly, it could _save_ you a line of 
code. It also better enables those _rare_ cases where you actually want to 
call getOpt twice as well as make it possible for getOpt to be pure for those 
rare cases where that might matter - all at no cost to 99.99% of the uses of 
getOpt.

> I kindly suggest we stop the isometric workout and look into adding good
> value to Phobos.

Someone else has been working on improving some of the guts of getopt. I was 
merely pointing out a place that it could be further improved as part of that. 
The extra work would be minimal and give a net improvement IMHO, and if the 
defaults are changed at all (which there is some reason to do due to a new 
value in the config enum) or if getopt is changed to getOpt to follow the 
naming convention, then we'd be making a change anyway. So, this small change 
that I'm suggesting wouldn't really create any issues or affect much code at 
all. It would just improve the basic module design.

- Jonathan M Davis