Re: Odd observation during debugging

On Wed, Jul 11, 2012 at 11:05 AM, Christopher Schultz
<[email protected]> wrote:
> Nathan,
>
> On 7/11/12 1:35 PM, Nathan Bubna wrote:
>> Actually, i still consider [the toString behavior] 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()
>
> If the ordering of the checking is really done that way, then my huge
> lists (which shouldn't exist in the first place, really -- I know that
> part's my fault) would fall-through at case #5 (isEmpty)? It's not
> entirely clear to me what happens in this (List) case.

yes. no object that implements isEmpty() (which would include all
Collections and Maps) would continue checking beyond that step.

>> 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.
>
> And these would be introspected so they don't have to implement some
> kind of interface, right?

definitely.  VTL has pushed toward duck-typing for years now and
should continue to do so, IMNSHO.

> After banging my head against my own code trying to figure out why my
> non-template-defined Lists weren't being wrapped, I realized that the
> contents of the Request/Session/Application attributes are *not* copied
> into the Context... they are fetched when requested. That means my code
> needs to get a bit more complicated if I want to wrap collections that
> are fetched from the request attributes ;)

true.

> This code is really crappy... but do you think it would be useful for
> anyone? I'd be happy to post it somewhere.

i have no idea.

> Thanks,
> -chris
>