Redefining truthy and falsey values


Consider adopting some behaviors from languages such as JavaScript or Groovy which allow for more clever conditional statements to be constructed. Consider this ticket a discussion on whether this is even possible and what implications it would have. I assume this might also require an on/off flag such as the null support feature.

This table outlines a suggestion of how the following values would behave when cast to booleans:






false if 0, otherwise true

String - Option 1

false if "0", or "false", or "no"; otherwise true if non-empty
"" throws exception

String - Option 2

false if "", or "0", or "false", or "no"; otherwise true if non-empty


false if empty, otherwise true


false if empty, otherwise true


true or based on CFC's toBoolean() method

This would allow for the full ternary version of the Elvis operator (Assuming full null support):

It would also simplify checking for the contents of structs and arrays:

I think these changes might be somewhat straightforward and mostly affect the Caster class, but most importantly:

  1. Do we want this in CFML?

  2. Would this have serious implications in backwards compatibility?

Other things to consider that are similar to Groovy would be Java Map, List and Iterator classes. True if not empty, or hasNext() is true.



Adam Cameron
February 11, 2016, 2:10 PM

> not be offensive to others

You're the only one taking offence, mate; and I wasn't even talking to you.

And there was nothing blimin' offensive about what I said anyhow. What Micha wrote really isn't that clear, and I think it's mostly down to his command of English not being that excellent. There's nothing wrong with that, but it gets in the way some times.

You seem to be looking around for things to be offended by. I think that's not a good use of your time, and it's not a good use of anyone else's time when you find something to be offended by and tell us. It also doesn't present you in a very good light. I recommend you don't bother.

Igal Sapir
February 11, 2016, 2:12 PM


Michael Offner
February 11, 2016, 3:27 PM

Let me make an other more simple example:

In ACF you will get the output "java.lang.String" and in Lucee "java.lang.Double" ( that is the reason I did 1+1 in the first example, to have a double with both engines, to keep it simple).

My point is that simple types in CFML are not that clear at all for the average CFML developer, even you are using a literal value or the type of a function argument is clearly defined, you still can have a different type as expected. So the cast of a simple type has to be as clear as possible, so for example "0" and 0 always need to have the same meaning in every context (expect things like jsonSerialize of course).

One point I completely miss in this ticket btw are date objects, they are also simple types, mean you can also convert them to numbers,boolean,strings ...

If someone does not understand what I'm writing and he is interested in what I'm trying to say, he is welcome to ask for clarification, something I do a lot myself in English conversations. So thanks for the clarification on my comment.

Adam Cameron
February 11, 2016, 3:57 PM

Cheers for the elaboration Micha: that's all very clear now.

Given this:
> so for example "0" and 0 always need to have the same meaning in every context

I now think even more that this is a complete no-go for CFML. But with .lucee as you don't need to be hung-up by CFML's need to "0" and 0 to be boolean equivalents, then this is less of an issue.

Ed Sanford
February 16, 2016, 7:00 AM

I would go a step further, and provided a flag allowing it were set, treat not only 0,"0","no","false", false, null and empty as false but undefined as false as well.

I like the idea of being able to write less code while still having it be readable, more often.

would be


Michael Offner


Brad Wood