[stringtemplate-interest] difficulty using format and null options together

[John Snyders]

Terence Parr wrote:
>
> On Mar 20, 2008, at 6:55 PM, John Snyders wrote:
>> I wonder if the following would work.
>> When the null option is used the string value is wrapped in a class such
>> as NullDefault. This simple class acts much like a string and toString
>> just renders the wrapped string. So because of the way ST default
>> rendering works it should just call toString and get the intended
>> default value. When the NullDefault object is passed to the format
>> renderer it will be able to distinguish it from a normal string. This
>> could still have some backward compatibility problems depending on if
>> people wrote robust renderers that called toString on objects they
>> didn't recognize.
>>
>> Terence, what do you think? Is this worth doing or will it cause 
>> problems?
>
> very interesting John.  Your thing that I'm wondering about is the 
> fact that the null argument can actually be a template not just a 
> string. In his case he could use maybe null={NULL} instead of 
> null="NULL" and then distinguish string from the template...or if you 
> is doing that check, why can't he just check for "NULL"?
>
> Ter
>
The trouble with the null argument being a template is that it is 
converted to a string first. In other words it is evaluated first. So 
the renderer couldn't check its type. You can check for the special 
string "NULL" but in doing so you exclude" NULL" from being a legal 
value of any other attribute or template result that is passed to the 
renderer. You could pick any other string to be the "out of band" value. 
It requires that your application has some reasonable out of band value 
that you can use. Not all applications will have that. In any event null 
makes sense as a reasonable out of band value for any type. That is why 
it is attractive to use it here.

-John