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

[Sterling Clover]

I think I'm late to the party here, but I really dislike this change.  
The functionality you describe is indeed mostly missing without it,  
but the change feels semantically hackish. It feels cleaner to reason  
about a language where a template *always* produces a value than one  
where a template optionally produces one. For example, this is what  
you describe:

<names:{n | <if(n.cool)><n><endif>}; separator=",">

But what about this (note the extra whitespace):

<names:{n |  <if(n.cool)><n><endif>}; separator=",">

To have the two behave so differently seems very unintuitive.

What I think you really want is something closer to standard list  
comprehension syntax, where a list is filtered on a condition. Since  
this provides the same power as what you've got below, I don't think  
it would hurt the logic/view split that stringtemplate enforces, and  
it would make templates more concise and readable. Now as to what the  
syntax is, that's a different issue. Something like the following,  
perhaps?

<names:{n: n.cool | n}; separator=",">

The problem here is of course the colon is somewhat unintuitive, but  
the standard set builder symbol for "such that" is the vertical bar,  
which is already taken. Other suggestions, all equally not ideal,  
follow:

<names:{n st. n.cool | n}; separator=",">
<names:{n & n.cool | n}; separator=",">
<names:{n when n.cool | n}; separator=",">
<names:{n where n.cool | n}; separator=",">
<names:{n % n.cool | n}; separator=",">
<names:{n ^ n.cool | n}; separator=",">

You get the idea.

Cheers,
Sterl.

On Jul 2, 2009, at 2:47 PM, 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?
>
> Ter
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest