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

[Monty Zukowski]

I vote to fix it. It won't break any of my templates and I think
you've nailed down the behavior I would have expected anyways.

Monty

On Thu, Jul 2, 2009 at 11:47 AM, Terence Parr<parrt at cs.usfca.edu> 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
>