Re: Odd observation during debugging

Nathan Bubna <[email protected]>
Newsgroups gmane.comp.jakarta.velocity.user
Message-ID <CAFyaDjGSWUmAT3D0TGztsLXWbyGumG=BEe6rYE1qFGH=6AFGHA@mail.gmail.com>
On Wed, Jul 11, 2012 at 9:58 AM, Christopher Schultz
<[email protected]> wrote:
> Nathan,
...
>> See VELOCITY-731 and VELOCITY-692 and others...
>
> Those were good to read: 1.6 introduced more consistent (if slower)
> treatment of references and then a setting was added to get the old
> behavior.
>
> Any idea if a future version of Velocity (maybe 2.x) will have the
> default value of that directive set to "false" so that toString will
> only be called for users who actually want that?
>
> While backward-compatibility is certainly a reasonable goal, this
> behavior kind of sucks... and I can't really think of too many cases
> where it makes sense. Good that there is a setting for it ;)

Actually, i still consider it correct for a template language (which
is not the same as a scripting language) to treat render-as-empty as
false in an #if.  So, my hope for 2.0 was to not to remove that
behavior, but to pre-empt it.  On your large lists, it would never get
around to checking toString(), since it would find isEmpty() and use
that.  IMHO, the lookup order ought to be something like this:

#if( $obj ) will be false if:

$obj is null
$obj is boolean false
$obj returns false from getAsBoolean()
$obj is empty string (CharSequence w/length 0)
$obj returns true from isEmpty()
$obj is array of length 0
$obj returns null from getAsString()
$obj returns empty string from getAsString()
$obj returns null from getAsNumber()
$obj returns empty string from toString()

So the config switch would stay, but in far more cases, it would be
unnecessary.  The vast majority of slow toString() impls are
collections or maps.  Other custom objects (see Apache Click) would
easily be able to avoid toString() by having an isEmpty() or
getAsBoolean() method.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.