On Mon, Jan 30, 2017 at 1:33 PM, Claude Brisson <cla...@renegat.net> wrote:
> On 30/01/2017 22:08, Nathan Bubna wrote: > > 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. >> >> That should be enough, yes. > > I like this syntax trick, but it remains a trick, so I won't stand for it. > Let's forget it. > > However, I wonder if we should rework the lookup chain so that it never > reaches bottom methods for standard types, collections and arrays. The > lookup chain may pretty well mix false and true checks. Like: if it's an > array, return whether or not it's empty and don't go further. Good idea. Once we find a method for checking (whether for null, false, or empty), then we should take its answer and go no further in the chain.
