Looks sound, nothing to complain here.
Am 2017-02-07 um 02:42 schrieb Claude Brisson:
Another try:
1) return false for a null object
2) return its value for a Boolean object, or the result of the
getAsBoolean() method if it exists.
3) If directive.if.emptycheck = false (true by default), stop
Another try:
1) return false for a null object
2) return its value for a Boolean object, or the result of the
getAsBoolean() method if it exists.
3) If directive.if.emptycheck = false (true by default), stop here and
return true.
4) check for emptiness:
- return whether an array is empty
Am 2017-02-06 um 19:45 schrieb Nathan Bubna:
On Mon, Feb 6, 2017 at 10:32 AM, Michael Osipov wrote:
Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov
wrote:
7) check object for a length() or size() method, if so return whether it
returns 0, but
On Mon, Feb 6, 2017 at 10:32 AM, Michael Osipov wrote:
> Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
>
>> On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov
>> wrote:
>>
>>> 7) check object for a length() or size() method, if so return whether it
>>>
returns 0, but I agree with Alex Fedotov th
Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov wrote:
7) check object for a length() or size() method, if so return whether it
returns 0, but I agree with Alex Fedotov that we could skip those
methods if we already took care for strings and collecti
On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov wrote:
...
> 4) check for empty objects by class:
>> - return whether the collection is empty for a Collection object
>>
>> 5) check object for an isEmpty() method, if so return whether it
>> returned false
>>
>
> Why explicitly check for collectio
Hi Claude,
Am 2017-02-06 um 17:55 schrieb Claude Brisson:
Hi Christopher.
The spec has evolved quite a bit since then: the course I've taken is
this one (and remarks are welcome):
4) check for empty objects by class:
- return whether the collection is empty for a Collection object
5) check
Hi Christopher.
The spec has evolved quite a bit since then: the course I've taken is
this one (and remarks are welcome):
1) return false for a null object
2) return its value for a Boolean object, or the result of the
getAsBoolean() method if it exists.
3) If directive.if.emptycheck = fal
On Mon, Feb 6, 2017 at 7:48 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Claude,
...
> > $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
I would try to something similar to Javascript convention
https://javascriptweblog.wordpress.com/2011/02/07/truth-equality-and-javascript/
substituting CharSequence instead of String (so that other empty String
like objects i.e. StringBuilder would evaluate as false) and also treating
empty arrays
Claude,
On 1/28/17 10:15 AM, Claude Brisson wrote:
> 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)
On Mon, Jan 30, 2017 at 1:33 PM, Claude Brisson wrote:
> On 30/01/2017 22:08, Nathan Bubna wrote:
>
> On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson
>> wrote:
>>
>> On 28/01/2017 20:23, Alex Fedotov wrote:
>>>
>>> You guys should definitely leave a way of disabling the toString()
>>>
conve
On 30/01/2017 22:08, Nathan Bubna wrote:
On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson 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 i
I guess I was not clear enough.
This option does indeed exist in 1.7. I just wanted to make sure it does
not get dropped in 2.0 as part of the cleanup work.
Alex
On Mon, Jan 30, 2017 at 4:04 PM, Nathan Bubna wrote:
> On Mon, Jan 30, 2017 at 12:51 PM, Nathan Bubna wrote:
>
> > On Sat, Jan 28,
On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson 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
On Mon, Jan 30, 2017 at 12:51 PM, Nathan Bubna wrote:
> On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov wrote:
>
>> You guys should definitely leave a way of disabling the toString()
>> conversion in boolean expressions.
>>
>
> Seems reasonable, and also familiar; this may have been discussed bef
On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov wrote:
> You guys should definitely leave a way of disabling the toString()
> conversion in boolean expressions.
>
Seems reasonable, and also familiar; this may have been discussed before.
> There are many places where people do null checks if #if
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
23 matches
Mail list logo