Forums Feature Suggestions -un of /set for /var

Since we can now use var -g to set several global variable, it would be nice to be able to use the -u switch of /set with /var.
The -n switch is also something I would like to be able to use

-u doesn't make sense in a local variable (because of the way mIRC triggers timer events and the single threadedness of script execution, -u can never actually trigger until the alias ends anyway). I assume this is to be used with -g, so if you need to set a global variable with an unset timer, why not just use /set? As far as "plain text" goes, just use $(text,0). If you want the features of /set, just use /set.

Indeed:
Because it totally defeats the purpose of using var -g, I wouldn't suggest it otherwise.
No, the -n switch let you prevent the calc feature, ie "var -s %a $(1 + 2,0)" displays 3. The -l switch of /set is undocumented so arguing that I should use /set with an undocumented switch to use -n to make a local variable make little sense, and it is also against the point of using var -g.

Actually, -gu would be rather very handy for cross-alias local variables. Many scripts currently use /set -u %var foo (for things like multiple returns and such) ; simply expending that feature for /var would be a nice addition.


Not only does that not work (var -s %x $(4 + 1,0) => * Set %x to 5), but for most cases where you actually do need to evaluate it as plain text, you can't really use $(,0) since you want to evaluate things. Of course, like always, obscure workarounds exists. But that's what they are, workarounds.

Being able to use all these features with multiple variables are the entire point of that feature suggestion.

What?? So you're not allowed to use undocumented switches now? If anything, you should be opening a bug report to document -l, not asking for a new feature because an existing feature is currently undocumented. If you know about the feature, you should use it, the fact that it is undocumented is likely an oversight, not an implication that you should be avoiding it. Indeed, if you want the behaviour of -n, you should be using /set -l. There's no need to have the same behaviour in different places. The only argument I could see would be the ability to set multiple global variables with a timer at the same time, but IMO that argument doesn't really stand up to practicality. The fact is we already have a way to do exactly what you need, so it seems to me as though you're just requesting this feature for the sake of keeping Khaled busy. I'd like to think he has better features to work on than adding new ways to do the same things.

Except that you couldn't use -n with multiple variables, so it's not the "point"-- that would defeat the purpose of the "treat data as plaintext" concept. In other words, if -n was used, mIRC could not be able to tell that a "," was used to separate variables, because it's supposed to be treating the data as plain text-- that's what you asked for, right? Otherwise you would need -n and yet another "REALLY, I MEAN PLAIN TEXT!" switch to tell mIRC not to parse ", %var2 = .... " as anything special.

The only thing you COULD use multiple variable setting for would be with -gu, but as I said above, you can already do this. Yes, I agree it's more elegant to user /var over multiple /set's, but let's not kid ourselves, this is mIRC script-- "more elegant" doesn't really hold much weight, IMO. The way I see it, if you can script it with /set and it's not horribly inconvenient (/set is not significantly more inconvenient, in this case), why do we need this? "Just cause"? Seems like there are better things Khaled should be focusing on.

Rather for convenience than anything else (var -g was added for that reason no?) and it just seems weird to use an undocumented switch that is, afaik, only supposed to be used internally.

But you have a good point with -n meaning it should treat value as plain text, causing issues when setting multiple variable with /var. The routine could be extended though I admit it might not be a good idea

vs.


Which would you prefer to do?

So I support the idea of -guN.

I personally prefer /set and would use your second example. I just feel that setting multiple vars on a single line can make the code harder to read. Like when debugging other peoples code (which I usually just ignore and code from scratch any more, for many reasons).

Really? I got that vibe from my second example...

I actually see the set as more readable, but even if we disagree, I see that example as somewhat of an edge case. You're not going to see that kind of code a lot (you shouldn't anyway), and if you do and it looks ugly, it's probably because it shouldn't exist. Setting a whole boatload of global variables on timers smells of bad code to me... I really doubt that would be the worst of the readability issues in such a script. Of course, that's no reason not to add it, but like I said, IMO these scenarios are fairly uncommon-- why optimize readability on the uncommon scenarios?

The second option is more readable to me as well. Yes, the first one is shorter, but the second is more clear imo.

I should point out that in a script file I rarely stack multiple commands on the same line in the first place unless it's only 1 or 2 commands (and would recommend others did the same), so it would actually look more like:



Actually, I'd find it hard to argue that this is less readable than var.

As a sidenote, if you really DID need to unset multiple variables at the same time, perhaps /set -u isn't even the best way to go. I'd probably do:



Not sure which one is easier to read, the latter is easier to maintain, though.

And you could do the same with /var -g and /timer, of course.

The purpose of the '-n' switch is to prevent the value, after regular evaluation, from being interpreted as a calculation.

I can't check right now, but I'm sure /var -g still calls /set several times as is typical of /var. Having all extra switches supplied with -g passed on to /set would be trivial to implement and would improve the command, imo.

(I couldn't follow the thread on my phone very well so apologies if I missed something :p)

At the end of the day, it all depends on what you see fit. We all see things differently with our distinctive tastes toward them. You may see a guy being handsome or a girl being ugly, but other people may perceive them being easy on the eyes.

My original suggestion for -n was about /var -n only, not var -gn.
I thought like argv0 that it would be a problem but in fact, each assignement is probably known/done before -n is applied, so it is actually possible to implement var -n on its own.
But sure -gn should also be supported.

I'm not sure why you feel the need to argue with almost every suggestion or bug report people make. This is a perfectly reasonable suggestion and there's absolutely no reason why it shouldn't be implemented.

/var -g allows you to create a global variable, so it should have the same features as /set does. There's not really any reason why it shouldn't. And I doubt something this trivial will be "keeping Khaled busy."

If you have nothing useful to say, don't say anything.

Note that I'm not disagreeing with the suggestion, I'm simply offering simple alternatives. I'm of the opinion that we should keep feature bloat as low as possible and not duplicate functionality across different functions unless there is a significant improvement in the API. In this case I don't see a significant improvement.

I think it's useful to point out that you can already do this with /set, just not with multiple vars at once, but the use-case for multiple vars at once is yet to be seen. As I mentioned, you might see the need for this once or twice in a script. But would you really break your scripts back-compat (seeing as this wouldn't work in 7.22 and earlier) just for a completely cosmetic change that occurs once in your entire script?

I also don't buy the argument that we should add this "because /set has it". /set -l can create local vars, so should we be adding multiple assignment to /set, then? Why should /var have the same features as /set if /set doesn't have the same features as /var? It seems to me that the reason different commands have different features is precisely because they are different commands. Yes, you would get multi-assign by adding the functionality of /set to /var, but again, the actual benefit of this is really not obvious (to me, anyway). It's a nice thought that when something is a small change it's easy to just do it in addition to everything else Khaled is doing. But realize that ultimately, Khaled's time is limited, and ultimately, he will be deciding to implement this instead of something else, for the next version. I'd rather see him squash some small but much more important bugs like this, which is likely to take as much time to fix/test.

I'm not sure both of the commands need identical features, but there's no point in having both commands with a unique feature. Might as well have one command that does everything and one that is limited (if they're not both going to have every feature).

At the moment you have one command for setting global timed variables, and one command that lets you set multiple variables at a time. Might as well have at least one of those commands support both.

Plus Khaled can manage his own development plan; I wouldn't let that concern you. Just comment on the feature suggestion itself rather than whether you think it's a waste of Khaled's time.

argv0 still makes a great point that if you were to use something like this, which is highly cosmetic rather than actually beneficial, that you would be limiting your script to only newer versions of mIRC. Maybe a scripter wouldn't care about that, but I think most people want to maintain compatibility with older versions as much as possible until it becomes inconvenient such as not being able to use $v1 (something that is very beneficial).

As to your first comment about two commands... based on your thought that one command should do everything, then why bother having two commands at all? If you're going to use that reasoning, then let's just drop one altogether and put everything into one command. Sure, it breaks scripts, but it is better than saying that one command should do everything and the other should do very little. Either two commands should do two different things, or there should be one command.

That's not really a good point at all and your example of using $v1 is especially bad as it's identical to the much older $Ifmatch. $v2 would've been better :p

As you stated yourself it's up to the scripter to decide if compatibility is important.

I would quite agree that there's no point in having both set and var if this was an alpha version of mirc v1.0, but as both commands have been around for so long it's not an option to remove them. As both commands do very similar things, not allowing var to set timed unset variables is a very arbitrary limitation. I would say it makes more sense to allow /var to do everything as changing the format of the /set command to allow multiple variables could affect backwards compatibility.

The argument that /set can already do these things became somewhat invalid when /var -g was added.

Again, not sure why a simple and reasonable request is receiving such opposition.

Typed this post on my smartphone so sorry if formatting/spelling is dodgy!

$ifmatch2 exists
Anyway, I strongly agree that people should comment about the suggestions and give their opinion rather than letting the question 'would it waste Khaled's time?' taking over their mind.

Didn't know about $ifmatch2 :p Well my point stands about both of them then!

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.



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.



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 can't remember why, but I faced a simple case where I could use two -uN global variables to solve the problem, I could have used /set (probably what I did anyway).
/set is fine, but if every suggestion were to be rejected because you could do it another way, mIRC wouldn't be what mIRC is, with the pros and the cons. Now when I faced the problem I simply thought "Ok it would make sense to be able to use -gu", I tested it and it wasn't working, and voilà. Not only it would make sense to have it, but as said it would improve the command.Noone ever suggested that this should be a priority, I actually still have several suggestions that I'm waiting for, that are much more important than this one, it's not a reason to stop making suggestionThis is probably where we disagree with you, I don't think such an addition can be called "major bloating the language", can you give an example of a bloat in mIRC? It's not because there are multiple way of doing something that it is a bloat, imo.
Knowing you are against var -g, I'm not trying to convince you, but it looks unfair, obviously you don't want -gu/n.
Fair enough but as I said -gun would be in continuity of var -g, for convenience, of course I admit people wouldn't use that very often, just the same a lot of others things are rarely used in mIRC.

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.



/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'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?

Your example user scenario doesn't really fly. A user looking up /help /var will be in the wrong place anyway (why was /var their first choice anyway? that seems arbitrary). If we're going to talk about user confusion in the help file there's plenty to discuss. The -g switch on /var is an after-thought in the documentation, it's a tiny phrase in a note at the end of the section titled Local Variables. It doesn't even get a full sentence. I'd be surprised if the user even found that /var could be used for global vars in the first place without paying very close attention (and ignoring the title's own heading saying those variables will be local, which would contradict the amount of attention he is supposedly paying).

So when he gets to (which he won't, he'd get stuck way earlier, most likely, but let's pretend):



The answer is simply: "/var is documented under 'Local Variables' and is for local variables, /set is for global variables." -- I don't think anybody will be confused by this answer. If they actually catch the doc on -g and ask why /var can set global variables, you tell them "/var -g was feature creep and shouldn't have been added." Simple enough to me.

And come on, those feature examples are easy to justify for the most part. Your assumption that they are simply "options for simplicity" is actually dead wrong. Most of the features you named have little to do with simplicity and a lot to do with reducing error-proneness or improving performance of the language, which is a common and valid justification for a feature:



While loops are a much more reliable way to loop. While loops were added because users were commonly having a difficult time with the error-proneness of goto loops, specifically in forgetting the goto statement, or, in nested cases, goto'ing the wrong label. While loops take one command out of the picture, give users indenting and make it easier to read / debug. It's also more reliable because users coming from other languages will be much more accustomed to this syntax than an archaic goto, again reducing error-proneness. There was a significant measurable success rate improvement in this addition, at least I certainly recall one when I was helping in #mIRC during the times before and after it was added.



Really? You're questioning "else"? There is a significant reliability advantage to NOT having to rewrite your if condition in the negative form. It's also much more efficient and performant to not have to re-execute this. Arguably, "elseif" need not exist, but it existed long before most other features, so it would be hard to call this one "feature creep". I think the fact that just about every other language has else is reason to follow along and implement this as well. There is good precedent for usefulness when 99.9% of languages have a feature.



Performance. mIRC is slow. If mIRC's file handling commands were as fast as /filter, you're right, we wouldn't need it at all. But mIRC is not that fast, and /filter is absolutely mandatory for a reasonably fast script, in countless cases. There is certainly a convenience element to /filter as well, but there is a much greater benefit to removing an entire loop structure than replacing "set %a | set %b" with "var %a, %b" -- there is also a small reduction of error-proneness in being able to remove a loop structure, as loops tend to cause many problems with new scripters, but this is certainly not the primary motivation for /filter IMO.

Finally, one you're right about:



I would argue that /close -@ should not have been added. Not only is it a horrible switch name (in fact, the only non-alphanum switch in all of mIRC, even /filter uses -w), it's unnecessary. But this is actually a great example of why we don't want to repeat the past, and actually helps to prove my point. We don't need more situations like /close -@... we should be striving for fewer of them. I bet the argument for /close -@ was the exact same argument as this one: "why not, /close can close other windows, -@ makes sense". This is precisely why I disagree with that logic.

In any case, as I had already stated, existence of bad examples in mIRC is no excuse to make mIRC messier. No, mIRC is not perfect. And no, that's not an excuse to make it worse.

I swear you would argue that the sky is green if the mood grabbed you... :p

All of this, pages and pages of discussion, over a simple request.

Admittedly some of my examples (i.e. elseif/else, while loops and /filter) were a little extreme as they're all very useful, but my point is that mIRC, and indeed lots of other languages, have multiple ways of achieving the same thing. Seeing as mIRC has already added /var -g, it may as well have /var -gu.

We only live once and I'm going to waste no more time on this. I've said what I think.

/set -u stores the variable in the vars.ini file. This is also true for /set -e. If you reload the var file the -u and -e are undeclared making a standard extern variable.

Just thought I'd stick my beak in a bit here.

Whilst I agree that the change is trivial, I don't see why argv0 or anyone else for that matter doesn't find using a switch to set options for multiple commands a better way of performing the operation.

Sure it may break backwards compat - but you can echo this to the user. They SHOULD be using the latest version anyway - and if they don't then tough cookie.

In programming you have a framework to make your life easier and to prevent lots of duplication and headaches do you not?

Take this PHP example:



Why would I want to put that function over and over again in my files? So we include the file or put it into a class.

Why would I want to increase each item in my array separately when I know I could just do them all at once?

I don't understand the purpose of your example... firstly because it has nothing to do with /set, but more importantly, you created a custom function to perform something PHP does not support natively. This is exactly how we should be using mIRC in uncommon scenarios. It seems to illustrate my point better than it does yours. Yes, you can create a function that factors out duplication, this is not a surprising concept. You can do the exact same thing in mIRC:



PHP doesn't have this builtin and won't, but if you need this behaviour, you can add it and make your life easier. So why is it so wrong to share this same paradigm in mIRC? Why is it that in mIRC, the functionality must be builtin, but in PHP it seems okay to code it yourself?

The heart of this issue from my end isn't about how much easier this makes your life, it's about how common the need for such a feature is. I'm sure for that a very small number of people, this might actually be useful. The keyword being: a very small number of people.

The problem with features used by a very small number of people is that it increases maintenance strain. If -u were to ever change in /set, it would now have to be synchronized with /var. This may or may not happen properly. Worse yet, since only a small number of people actually use these alternate features, Khaled may forget about updating them in the future, and this may go un-noticed until after a release. Problems like these have happened before. He likely started to release public betas for this very reason-- but with such a small number of people making use of some functionality, a public beta might not even catch some of these issues.

You might be saying, "well it's only one more thing he has to think about, you're exaggerating the problem!" ...it's one more thing here. And one more thing there. And another thing in the other suggestions. The amount of things Khaled has to think about when making changes is probably fairly surprising. This makes it harder for him to make changes without worrying that something else will break. And all this just for a handful of people that could have written an alias to remove the duplication in their own script.

Ultimately the question is: why is it necessary for mIRC to support this builtin, but completely out of the question for the handful of scripters who want it to just make an alias for it themselves? Why is the onus always on mIRC to support all functionality?

Right but the fact is, as you and others pointed out. It's supported with var which effectively does the same thing as set.

Yes it can be done with a simple alias, but if mIRC already supports it via a very similar command, it should be relatively easy to implement this onto another especially since it already supports switches.