On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson <cla...@renegat.net> wrote:
> 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 call. Even worse some classes may use toString for debugging >> purposes and produce very long strings (including nested objects, etc.). >> In the code above that would be a huge inefficiency. >> > > I totally agree that a great percentage of #if($foo) statements are just > here to check for nulls. And the current behavior of returning false for > empty strings, empty arrays and empty maps could already be problematic in > this regard > > And I think I have a good proposal about that. > > Since > > $foo differenciate null and "" (by displaying the first and not the second) > $!foo assimilates null and "" (by hiding both) > > why not consider that: > > #if($foo) returns false for null and true for everything else, and > #if($!foo) returns false for null, "", zero, empty arrays, etc... > Yikes. That looks like a scary combo of significant and subtle. It would need to be well-highlighted in the release notes, change logs, docs, etc. I might like it. Maybe. I dunno. The syntax is giving my tired brain spasms, given that it's close to the very different #if( !$foo ). I can't "read" it, if that make sense. It's like a complex regexp, where i have to think my way through it, instead of just reading it. Is there a use-case for having both supported in the same template? Otherwise, it might be better to avoid the subtlety and just support a configuration property for how clever templates can be with evaluating #if( $foo ). Maybe we do the full lookup chain by default, but let people set a directive.if.emptycheck = false That would limit it to just checking for false or null values (presumably still including getAsBoolean, getAsString, and toString), but skipping the "empty" checks. Then the high performance move is: directive.if.emptycheck = false directive.if.tostring.nullcheck = false But the default is for both to be true. > Claude > > >> Alex >> >> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nbu...@gmail.com> wrote: >> >> Shame that i can't remember anymore all my reasons for wanting those >>> "getAs<Type>" 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 <grin>), i wonder why i pushed for bucking the >>> "to<Type>()" convention. >>> >>> As for the literals, the thought of them being used in #if statements in >>> a >>> template language is cringe-inducing. What's the use-case? Temporary >>> debugging hacks? If so, part of me thinks maybe only 'true' should even >>> be >>> allowed. >>> >>> On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cla...@renegat.net> >>> wrote: >>> >>> >>>> 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 >>>>> assignee. You never know who handled it without reading the entire >>>>> thread. A ticket should always have an assignee if code has been >>>>> >>>> changed. >>> >>>> >>>>> Here's what had been specified by Nathan at the time (order is >>>> >>> meaningful, >>> >>>> and falseness seems easier to specify than truth): >>>> >>>> $obj is null >>>> $obj is boolean false >>>> $obj returns false from getAsBoolean() (provided there is such a method) >>>> $obj is empty string (CharSequence w/length 0) >>>> $obj returns true from isEmpty() (provided there is such a method) >>>> $obj is array of length 0 >>>> $obj returns null from getAsString() (provided there is such a method) >>>> $obj returns empty string from getAsString() (provided there is such a >>>> method) >>>> $obj returns null from getAsNumber() (provided there is such a method) >>>> $obj returns 0 from length() or size() (provided there is such a method) >>>> $obj returns empty string from toString() (provided there is such a >>>> >>> method) >>> >>>> Regarding this spec: >>>> - I'm not sure about getAsString() ; toString() is usually the >>>> standard >>>> way of getting the String representation and should be enough. >>>> - I'm not convinced by the fact that zero should be true. I hear >>>> >>> Nathan's >>> >>>> point that for a display language, zero is as legitimate as any other >>>> number to be displayed. But it breaks the principle of least surprise, >>>> since each and every other language around, when not forbidding number >>>> towards boolean implicit conversion, consider zero as false. >>>> >>>> So I'd rather go with: >>>> >>>> $obj is null >>>> $obj is Boolean false >>>> $obj is Number zero (whatever Number variant) >>>> $obj returns false from getAsBoolean() (provided there is such a method) >>>> $obj is empty string (CharSequence w/length 0) >>>> $obj returns true from isEmpty() (provided there is such a method) >>>> $obj is array of length 0 >>>> $obj returns null from getAsNumber() (provided there is such a method) >>>> $obj returns 0 from length() or size() (provided there is such a method) >>>> $obj returns empty string from toString() (provided there is such a >>>> >>> method) >>> >>>> Also, I noticed that Velocity weren't very consistent with literals. The >>>> only literal returning true is the 'true' literal. "foo" is false, >>>> >>> whereas >>> >>>> it should be consistent with $foo containing "foo". >>>> >>>> Claude >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >>>> For additional commands, e-mail: dev-h...@velocity.apache.org >>>> >>>> >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
