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
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:
Do we want this in CFML?
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.
> 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.
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.
Cheers for the elaboration Micha: that's all very clear now.
> 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.
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.