mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: Riamus2
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!

Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Quote:
$v2 would've been better :p
$ifmatch2 exists laugh
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.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Didn't know about $ifmatch2 :p Well my point stands about both of them then!

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: hixxy
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


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.

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


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.

Originally Posted By: hixxy
Again, not sure why a simple and reasonable request is receiving such opposition.


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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
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.
Quote:
priorities should shift to favouring more stability unless there is a significant advantage to a new behaviour.
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 suggestion
Quote:

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
This 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.
Quote:
I don't judge a feature by how simple it is, but how useful it is
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.

Last edited by Wims; 24/11/11 11:59 AM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: argv0
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.

Originally Posted By: argv0
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.

Originally Posted By: argv0
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?

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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):

Originally Posted By: hixxy
"Why doesnt /var support it?"


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:

Originally Posted By: hixxy
What is the point of while loops


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.

Originally Posted By: hixxy
what is the point of elseif and else statements


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.

Originally Posted By: hixxy
Why /filter when it can be accomplished with file handling commands


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:

Originally Posted By: hixxy
Why do we have both /close and /window?


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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
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.

Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
/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.


Beware of MeStinkBAD! He knows more than he actually does!
Joined: Sep 2006
Posts: 59
R
Babel fish
Offline
Babel fish
R
Joined: Sep 2006
Posts: 59
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:

Php Code:


<?php
 function add($array) {
  for($i=0,$c=count($array);$i<$c;$i++) {
   $ret_array[] = $array[$i]++;
  }
  return $ret_array;
 }

 $increase_all = array(1,5,9);

 var_dump(add($increase_all)); //should print 0 => 2, 1 => 6, 2 => 10
?>




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?

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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:

Code:
alias add { .... }


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?


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Sep 2006
Posts: 59
R
Babel fish
Offline
Babel fish
R
Joined: Sep 2006
Posts: 59
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.


Page 2 of 2 1 2

Link Copied to Clipboard