On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov <a...@kayak.com> 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($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.
>

Yes, that's part of the motive to have this lookup chain. If there's a
match higher up, toString() is avoided. Big deal for maps and arrays.


>
> 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
> > >
> > >
> >
>

Reply via email to