In my last post I discovered that ColdFusion
is the string
. You can compare it to a java boolean true using “is”, but not using .equals(). Fair enough, one is a string and the other isn’t. “is” is ColdFusion magic, and .equals() is just poor dumb java. And if you’re wondering, “eq” is just as magic as “is”.
Does that mean all ColdFusion booleans are actually strings. No! The result of a boolean expression in ColdFusion is actually a java boolean.
a = true; // this is a string b = "true"; // this is the same string - literally the same in-memory object c = a is true; // this is a boolean d = b is true; // this is literally the same boolean a is c; // this is true a.equals(c); // this is false // etc.
So it turns out that
is not, as I thought, a built-in boolean constant, it’s actually a special syntactical case for creating a string – that can then be used in ColdFusion boolean expressions. This is reminding me of my perl days (that’s a good thing – I loved perl).
If you never had to interoperate with Java none of this would matter. The booleans and strings intermix seamlessly within ColdFusion. If you do, it’s important to know that ColdFusion actually does not have any built-in boolean constants that Java will recognise.
myJavaFunc(true); // this won't work myJavaFunc(true is true); // Somewhat disturbingly, this will myJavaFunc(javacast("boolean", true)); // so will this myJavaFunc(CreateObject("java","java.lang.Boolean").init("true")); // and so will this
I’d tend to go with the third form using javacast. Use the second form only if you want to mess with your junior programmers heads 🙂 Reminds me of those crazy funsters who put “and 1=1” at the end of all their SQL queries.