I don’t know why, but i’ve always struggled remembering if CFIF uses IS or =. So i’m working on a project today and put = (instead of is) when checking a session var.
do this stuff
and i didn’t realize it, ran the code and was getting really unexpected behavior. i went back to the code and realized right away, “oh crap i put = again darn it!”
Typically i would expect a system to throw an error in this case, but instead it actually behaved like it was a and SET the session var to 1!
I wouldn’t think this is the desired behavior right?
java 1.8.0_121 64bit
windows server 2016 in a vmware vm
Not a bug are all, just a typo on your part It’s actually a valid option to set a variable in your if. Here’s an example of me doing that in the condition for a while loop.
Note, ACF isn’t cool enough to support this.
Thanks for the reply so quickly!
So just to confirm, in lucee:
run this stuff
SHOULD set myvar to 1?
boy I better stop making THAT typo!!! lol
Thanks so much again.
Can you name a use case for when a person would want this behavioral quirk in an if statement?
Loops. I understand, but otherwise this seems dangerous as in OP case.
The answer does seem tongue-in-cheek, but it’s worth risking the whoosh
Op—it might be easy to remember that cf kind of supports loose sentences. cfif variable is value and var2 does not contain “sub value”.
In some TryCF.com tests, I got some interesting results.
one = 0;
<cfif one = "1">#one#</cfif>
outputs 1, but
one = 0;
<cfif one = "test">#one#</cfif>
throws “Can’t cast String [test] to a boolean on line 6”
The edge-case situational mixed with cases where the syntax is valid are so rare, that I have to submit that it’s a detriment to devlopers.
I’ve also, in a few minutes’ testing, not been able to mix this with conditions like <cfif 2 eq 2 and one = 1>, throwing the expected "invalid-lefthand assignment>
In all these cases, if a developer absolutely wanted to set something in the if-line, they could write a function to do it. Even then, I can’t imagine why a cfset wouldn’t work better.
And none of this behavior even works in cfscript.
I think a lot of people tend to handle most of their logic in CFSCRIPT these days, but it still seems like asking for a security hole for tag-users making an innocent mistake.