[stringtemplate-interest] separator: a fix or breaking backward compatibility?

[Terence Parr]

we already have null="6" option which replaces null objects in  
iteration with 6 :)
Ter
On Jul 2, 2009, at 12:51 PM, Jim Idle wrote:

> Terence Parr wrote:
>>
>> Hi,
>>
>> I've built an awesome example using ST for the book. Given a single
>> Class object, ST will generate all of the SQL and Java code necessary
>> to serialize and deserialize objects of that type. no Java code used
>> at all to generate the output :)
>>
>> HOWEVER, it exposed a serious problem in ST behavior.  Unless I can
>> fix this, I will have to add some Java code to do processing to
>> generate the SQL, which I don't want to do.
>>
>> Consider the following generation of a comma separated list of names:
>>
>> <names; separator=",">
>>
>> There is a separator generated in between every name in the list. If
>> names is null, nothing is generated. If names has length one, there  
>> is
>> no separator generated.
>>
>> Now, consider the following anonymous template application to a list
>> of names:
>>
>> <names:{n | <if(n.cool)><n><endif>}; separator=",">
>>
>> It will only a name if that name is "cool" (has field cool true or
>> method isCool() true). The problem is that when n.cool is false, you
>> still get an operator.
>>
>> This is a serious problem in terms of generating output because there
>> is no way to get around this bug or feature! The answer must lie in
>> what the result of a false IF is exactly. Is it missing (null) or
>> empty ("")???
>>
>> If the result is missing, then no separator should be generated.
>> However, if it's empty, we should get a separator.
>>
>> I'm proposing that the result is missing not empty. If we truly want
>> empty, we can do this
>>
>> <names:{n | <if(n.cool)><n><else><endif>}; separator=",">
>>
>> The else clause is present but empty, right?
>>
>> I'm not sure how hard it is to fix this IF problem. But, I need a  
>> vote
>> from people to tell me if it will break something they rely on.
>>
>> This would be a bug fix release like 3.2.1 or perhaps 3.3 if I add  
>> any
>> small features. This will not be the overall rewrite, which I will
>> begin after the book.
>>
>> Amazing how writing a book exposes all of the weird nooks and  
>> crannies
>> in a tool. Ha! Book-driven functionality testing :)
>>
>> So, should I "fix" it?
>>
> I can't think of anything I use that would change if you changed  
> this behavior, but I can imagine that other things might.
>
> How about:
>
> <names:{n |<if(n.cool)><n><endif>}; separator=",", skipifempty,  
> skipifnull> /* empty is defined as "" */
>
> or similar, depending how you want people to think about this. I do  
> think though, that the original default probably should have skipped  
> the separator if the resulting value was null. But generally,  
> changing this after the fact usually breaks someone's work  
> somewhere, though I have trouble thinking of any practical  
> application for keeping delimiters when the value is null. It might  
> be though that people have inadvertently relied on this without  
> knowing it. For instance if you generate a function call where an  
> empty delimiter means use a default value:
>
> funccall(7,,7)
>
> deffun funccal(a=6, b=6, c=6,)
>
> Contrived perhaps?
>
> Jim
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest