[prev in list] [next in list] [prev in thread] [next in thread] 

List:       stringtemplate-interest
Subject:    Re: [stringtemplate-interest] difficulty using format and null
From:       Terence Parr <parrt () cs ! usfca ! edu>
Date:       2008-03-28 23:30:39
Message-ID: E7DCB28E-D8E6-4AB1-8436-505032B80644 () cs ! usfca ! edu
[Download RAW message or body]


On Mar 26, 2008, at 5:24 PM, John Snyders wrote:
> 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.

really!  ooops...that ain't no good.

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

I'm addding a bug to look at this.

http://www.antlr.org:8888/browse/ST-38

Ter
_______________________________________________
stringtemplate-interest mailing list
stringtemplate-interest@antlr.org
http://www.antlr.org:8080/mailman/listinfo/stringtemplate-interest
[prev in list] [next in list] [prev in thread] [next in thread]