Is this weird? The type changes to actual boolean ...
# lucee
d
Is this weird? The type changes to actual boolean on the 2nd dump. Or maybe I’m misunderstanding how
booleanFormat()
works? https://trycf.com/gist/e63f40983cb86a0b178bcc1ff4e8215f/lucee5?theme=monokai
a
Nope, not weird. Your third statement takes a string
'False'
, passes it to
booleanFormat
which returns a string
"false"
. You use that as the operand for the
!
operator which takes a boolean, so Lucee converts
"false"
to a boolean (
false
) and then evaluates the expression which is
!false
which is
true
.
😂 2
d
Ok, so booleanFormat() returns a string. The
!
operator is the thing that actually is able to turn it into an actual boolean. Got it.
1
a
Tbh, I've rarely used
BooleanFormat
so I was suprised it returned a string 😆
d
Yeah, I didn’t realize that. The name made me think it would return a boolean, but sure enough, the docs say string.
a
Exactly what I was thinking, lol
I guess with a name like "Format" it should've been obvious though
1
d
I guess it always trips me up that
'False'
is a string but
'False' EQ false
returns an actual boolean just fine. I was trying to avoid the whole
myVar EQ false
thing (which I now learned
booleanFormat()
will not get me closer to doing) but oh well.
a
If you can go
myVar EQ false
, then you can go
NOT myVar
or
!myVar
. You don't need to do anything else.
d
Hmm, I thought it tanked when I tried
!myVar
but I’ll check it out again.
a
oh
yeah hang on
"some string that ain't boolean" eq false
will be doing a string comparison, not a boolean check
d
My brain is melting with this, haha. Too late on a Friday for it all, it seems.
I think you’re right though, I can do
!myVar
since I have a string of
'False'
. https://trycf.com/gist/718f17b9b0939c9893d0f45b5e1bb05f/lucee5?theme=monokai
d
My guess is the
booleanFormat()
was designed to help get boolean-like variables to something that JavaScript will understand as a boolean. For example,
booleanFormat("Yes")
returns
true
, which could be used safely in JSON/JavaScript.
1
a
A situation caused in the first place by Allaire's stupid decision to have the string-conversion of CFML booleans to be "Yes" and "No". Planks.
d
While I understand trying to maintain backwards compatibility, using Yes/No was something they should have depreciated and removed before CF4 was released. Not migrating that to true/false, has historically been one of the biggest PITA issues with ACF.
a
Just to add to this. @Mark Takata (Adobe) I would dearly love to know what the story is here: https://trycf.com/gist/ef155255d25a922dfa5ca4cc58537c2b/acf2021?theme=monokai
Copy code
<cfoutput>
<cfset b = isValid("string", "my string")>
#b.getClass().getName()#<br> 
#b#<br>
#toString(b)#<br>
#b.toString()#<br>

<hr>

<cfset b = true>
#b.getClass().getName()#<br>
#b#<br>
#toString(b)#<br>
#b.toString()#<br>
</cfoutput>
Copy code
java.lang.Boolean
YES
YES
true
coldfusion.runtime.CFBoolean
true
true
true
Why... O why... are you using two different Boolean implementations? And why has the
toString
behaviour on the native Java Boolean been monkeyed-with to return
"Yes"
, but the special magic CF-Team-created one behaving as one would expect a sanely-designed language to?
m
I was probably drunk when I wrote that Adam. 😛
By the way, I'm going to be doing a webinar on all the weird boolean truthy stuff in CF in a few months. Also, did you REALLY say "sane" in reference to CF? 😄 We're all on this nutty journey together mate.
🙃 1
In all seriousness, this is an annoying thing, but because of the auto casting (and the "yes" yes etc stuff) I'm not sure what the ideal would be. What SHOULD the functionality be here? Removing the fuzzy casting is not going to fly but which type is the RIGHT type? Or does it not matter which type it gets cast to as long as it casts to ONE, consistently?
a
Hard to say. I guess there is a reason(*) the
coldfusion.runtime.CFBoolean
class exists, so I am guessing all booleans in CFML should be those. (*) not suggesting it was a good reason.
m
Thoughts on implementing the highly advanced quadribool in CF? 🤣
😡 1