im not sure if this is really a 'bug', but in my opinion the behavior of $ifmatch should be changed. currently, it returns the $ifmatch of the last if statement, regardless of its location in relation to the currently executing script. an example:
alias one {
if ($time) {
two
echo $ifmatch
}
}
alias two {
if ($version) { return }
}
the above code returns the version of mIRC you are using (the $ifmatch of the 'two' command), when (at least in my opinion) it should return $time (the match of the last if statement in the current procedure).
Yeah, it's been bugging me several versions now. It definitely should be changed imo.
Agreed, I've also noticed that.
Yeah, having to deal with workarounds for this isn't funny
.
an maybe it's good as it is....
I dont see what ya complaining about, $ifmatch does exactly what its ment to do, gives you the value of the first arguement of the LAST condition checked, if you want to go and run other code then try and come back and test it again, well to bad to sad.
The $ifmatch should only be used when u know exactly what the results could be. as soon as you do soemthing else well its a gamble, oh any you know how i said its the LAST condition checked, well look at the two lines below, you would think the results both would be Y but check it out....
if ((X == X) && (Y == Y) { echo result1 $ifmatch }
if ((X == X) || (Y == Y) { echo result2 $ifmatch }
result1 Y
result2 X
since X == X in the 2nd line is true the IF is valid and thus the Y == Y is never even checked
sorry i left a bracket of each line...
if ((X == X) && (Y == Y)) { echo result1 $ifmatch }
if ((X == X) || (Y == Y)) { echo result2 $ifmatch }
It could just be local instead of being a 'gamble'. Wouldn't make anything worse.
Your example is not related to what he said.
"[...] you would think the results both would be Y but [...]"
According to what he said, he wouldn't think that. $ifmatch would act in its scope, which is just fine.
The issue is when it's used from another scope, not another condition, and such change is followed everywhere else when it shouldn't (IMO too). There's a difference.
It's like you having an alias which sets a local variable %x, then calls another alias and this 2nd one changes %x's value.
BTW you didn't need those extra ()'s anyway :tongue:
your right about how it could be different, but there not going to change it, and I would be one of the first to start critizing if they did, changing the nature of a command could cause problems for any number of existing scripts, someone may already be using $ifmatch as a method of returning data from a called routine, even if there are more conventonal means to do it.
Now if a $ifmatchlocal was added that would be nice.
On the examples i showed, i wasnt meaning what he would like to happen i was meaning what does happen.
I have used this in its simplest forms like searching for a matching line of text in a file if its not $null do something with it, and rather than searching for it again, just using $ifmatch to retrieve it, and more complexely once or twice in a set of conditional checks where you might want to force a method as such
if ($1 == /me) || ($1 == /say) || ((%forcesay == $true) && (/say == /say)) { Sendtochannel $ifmatch $2- }
Or if you want to check a bunch of things and use the first valid one such as
if ($1 == Lisa) || ($1 == Jane) || (($1 == miss) && ($2 == Debbie)) { //say Welcome $ifmatch }
* ok that example is pretty lame, but shows how $ifmatch well pick out the name using $1 or $2
I like the command just as is, but i agree with you that it would be nice to have a reliable local $ifmatch
In fact I stuffed someone else script up once by having my own "alias echo" it checked some things then displayed text most of the time as normal, his script did a if then echoed something then used $ifmatch, by then i had caused $ifmatch contents to change, big oops.
Fixed it by storing $ifmatch contents then doing a.... if (%holdifmatch == %holdifmatch) { }
i cant amagine someone looking at my script later thinking , whats this crazy doing comparing if something is the same as itself then doing nothing.
PS: i love brackets, lots and lots of brackets ;-)))))))))))))
What I meant was $ifmatch would still pick the right parameter in your examples if it was local.
i guess we have differing opinions on how $ifmatch should operate. like i stated in the post that started this thread, my thoughts were merely an opinion.
on the topic of improvements or changes to $ifmatch, i believe the best way to modify it would be to treat it like an array, possibly containing the last 10 or 20 $ifmatches, which resets after each operation is finished.
in my example above, $ifmatch(1) could return $time, and $ifmatch(2) could return $version. in addition, a switch like 'l' could be added, making sure the list only applies to "local" $ifmatches, i.e. $ifmatch(1,l) in my example would return $time.
i would never have said anything about this, but i posted it right after i concluded that such behavior was the source of a bug which i had spent several days trying to track down.