Oh, and there is one exception: both of them should of course also be
false for the false boolean value. People willing to differentiate null
and false do have methods to do so.
Claude
On 29/01/2017 01:38, Claude Brisson wrote:
On 28/01/2017 20:23, Alex Fedotov wrote:
You guys should def
On 28/01/2017 20:23, Alex Fedotov wrote:
You guys should definitely leave a way of disabling the toString()
conversion in boolean expressions.
There are many places where people do null checks if #if($obj)...#end.
Classes almost never return an empty string or null string from the
toString ca
On 28/01/2017 20:06, Nathan Bubna wrote:
Shame that i can't remember anymore all my reasons for wanting those
"getAs" lookups. Wondering why getAsNumber and getAsBoolean are here
too. Anyone else recall the use case? And assuming that i had good reason
(that did happen sometimes ), i wonder why
You guys should definitely leave a way of disabling the toString()
conversion in boolean expressions.
There are many places where people do null checks if #if($obj)...#end.
Classes almost never return an empty string or null string from the
toString call. Even worse some classes may use toString
Shame that i can't remember anymore all my reasons for wanting those
"getAs" lookups. Wondering why getAsNumber and getAsBoolean are here
too. Anyone else recall the use case? And assuming that i had good reason
(that did happen sometimes ), i wonder why i pushed for bucking the
"to()" convention.
What is the problem?
Velocity "truthiness":
https://issues.apache.org/jira/browse/VELOCITY-692
It should definitely be part of 2.0. I missed it because the issue was
closed, we should have opened a 2.0 one to remember it.
Thats's the problem if a closed/resolved issue does not have an
assi