mIRC had a shorter release cycle when $v2 was introduced, and more people were on the latest version. Now we have many users on older versions (6.35 especially, given the unicode issues some users have) and mIRC has matured and the cycle slowed down, so it's not as easy to be as reckless. Yes, it's the scripter's choice to care about backwards compat, but the language shouldn't intentionally make it more difficult to make these decisions, especially information like when a switch was introduced on a command are slightly more obscured and harder to track. There were also fewer versions to deal with back-compat on. Also, $v1/$v2 wasn't strictly necessary either, and I'm not sure I would have supported it had I been active on the forums then, but again, 10 years ago was a different time for mIRC-- more delta is expected in a young codebase. mIRC isn't young anymore, priorities should shift to favouring more stability unless there is a significant advantage to a new behaviour.
I still don't see why you feel the need to comment upon priorities, length of time, etc, when ultimately that's up to Khaled. Let's just comment on the feature itself and not whether it's worth Khaled's time.
No, my silence on /var -g should not be interpreted as acceptance of it. I'm no fan of that switch either. Sure, it's too late for that one, but hopefully we can stop the feature creep before it gets any worse.
/var -g itself, if anything, was feature creep, but now that that has been added we may as well go all the way and support everything that /set does. There really is no reason not to.
I made it fairly clear why I "oppose" this request. It's easy to say "it's a small change, it will barely have any impact, so there's no reason to oppose it", but at the same time, it's small features like this that end up causing major bloat in languages/APIs down the line. Therefore, I don't judge a feature by how simple it is, but how useful it is. In my mind, a one line change is equal to a one thousand line change in terms of whether, in my opinion, it should be added.
As it stands, I don't see an apparent real world use case for something like this that extends beyond maybe 1 usage per ~1kLoC, generously. And that's for /var -g in general. How often does a script really need to set multiple global vars at once? In initialization, sure, possibly. Other than that? (Note: this would have been my argument to /var -g in the first place). Also, given that the convention of setting global vars is to prefix them with a scriptname, setting multiple %myscript.foo = somevalue, %myscript.bar = someothervalue doesn't even seem practical, since you end up with a ton of text on a single line-- certainly not more readable. And yet, all of this is again just for /var -g. /var -gu would probably be orders of magnitude less common. If you're only setting multiple global vars once or twice in the duration of a script, how many of those will really need -u? /set -u in itself is already fairly uncommon, and initialization wouldn't need -u, so we're left with the uncommon case of the uncommon case.
I'd really love to know if Wims would even ever need to use this behaviour himself (and how he would), as well as if anybody else would. I think showing that there is an actual user-base out there that wants a feature because they plan to use it, not just because they think it is a "nice idea", is the real test of utility. I'm not seeing this either. That's why I asked what is wrong with /set.
I'm of the pragmatic opinion that we should be adding things with real need rather than "just cause it's a small change and we can". The latter has no limit to what can be added, and creates a messy language-- mIRC is messy enough, but that shouldn't be an excuse to make it worse. This is of course my opinion only, but I'm just expressing my opinion on the feature, you can feel free to ignore my opinion if you like. You know, "if you have nothing useful to say", and all.
I've read all of your wall but I'm not going to reply in its' entirety, but I will reply to some specific parts: -
"How often does a script really need to set multiple global vars at once?"
As many times as it needs to. There are millions of possibilities of scripts that would want to set multiple vars at once, but one such example is when a dialog closes (i.e. saving configuration options).
"I'm of the pragmatic opinion that we should be adding things with
real need rather than "just cause it's a small change and we can". The latter has no limit to what can be added, and creates a messy language-- mIRC is messy enough, but that shouldn't be an excuse to make it worse."
You call that messy, but I think it's messier to have multiple commands that can accomplish the same thing, with only one of those commands having certain features.
Imagine the following scenario on a help forum: -
"How can I send a message when somebody joins, but only once every five seconds so I don't get flooded off?"
"Use a timed unset variable."
*user looks up /help /var*
"It doesn't seem like there is a timed unset switch for variables. I looked at /help /var"
"No you have to use /set"
"Why doesnt /var support it?"
Sure it's a very specific example, but that's what people will be thinking. Why can set set timed unset variables and not var, when they can both set global variables?
How often the feature will be used is immeasurable so there's no point of bringing that into the equation.
What is the point of while loops, what is the point of elseif and else statements (when you could just include multiple conditions in an if statement using &&), what is the point of a lot of things that were added to mIRC... to give the user options and for simplicity's sake.
Why do we have both /close and /window? Why /filter when it can be accomplished with file handling commands, window commands, $sorttok etc?
