Forums Bug Reports if (a =* b) not producing an error

i noticed this a while ago but never thought much of it. it seems that if (a =<something> b) is treated as if (a == b) and if (a ===<something> b) is treated as if (a === b). for example:



i used => since that's the example that just came to my attention. a fellow scripter has been using => to express 'less than or equal to' for a while without noticing the flaw in it :P

not too important, but i propose that it throws an 'unknown operator' error as it would in the following case:



can be a tad misleading if it doesn't throw that error

yes I would like it to return unknown operator error. because it would help much scripters out there.

I disagree with this proposed change, since this would also mean that:

Would fail, and throw a "unknown" opperator value.
Even though it should be:

That means you can no longer check if (<string>) to check that a string exists.

if (a . b) is basically a shorthand way of writing if ((a . b != $null) && (a . b != $false) && ($regex(a . b,/[^0]/)))

Why would that fail just because this bug was fixed? mIRC's parser is already smart enough to resolve operators and operands based on the number of arguments in a condition prior to evaluation so everything else would still behave correctly.

If mIRC behaved the way (I think) you're suggesting, the following code wouldn't work the way it does:


For the first line, mIRC sees that you've given three "arguments" in the condition so it treats them as operator, operand, and operator respectively. For the second only one "argument" is given, so it treats it as an implied boolean condtion (that the value of the variable is not $null, $false, or equal to 0). For the last line it creates an error because there's no way to know or guess what the scripter intended.

In addition to my response to Kardafol, I'll just point out that the condition you're using as an example will create an error for the reasons jaytea has mentioned. There's no way to check that string shorthand unless you assign it to a variable so that mIRC can make a reliable guess at what you want it to do. That's just a drawback of quoteless strings I'm afraid.

I agree throwing an error would be better for occasions like:
if (a . b)

why would you want to check if a constant literal string is set/exists ? It will always return true so its a waste to check.
mIRC is pretty smart about it indeed:

will still be treated as if (22 == 22)

in case of if ($hget()) its only paramater so
//hadd -m test test3 0 == 1 | if ($hget(test,test3)) echo -a $v1
will be true even tough the statement it evaluates to is false. This will also be the case if what jaytea suggested will be fixed.

However this:

wont echo.

edit: reply to kardofol not to you starbucks

I didn't think of that until after I'd already posted :p

There's no reason for checking that..

i worded my post wrong, i should've said 'as it does in the following case' instead of 'as it would in the following case' :P btw hixxy, think of the decimal point in if (0.0), if (a . b != 0) would take care of that

Thanks, this has been fixed for the next version.