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
