[stringtemplate-interest] String manipulations

[Zenaan Harkness]

On Thu, Sep 28, 2006 at 11:22:23AM -0700, Terence Parr wrote:
> On Sep 27, 2006, at 9:39 PM, John Snyders wrote:
> > However I think the implementation is independent of the syntax  
> > used. Why
> > couldn't option 4 ($name;format="upperCase"$) be translated to
> > r = renderer.get("String");
> > r.upperCase(name);
> 
> Interesting...ok, we don't want $x; format="y'$ to call x.y(), but we  
> can allow it to call $xClassRenderer.y(x)$.  That is better...
> 
> > The same amount of information is available to the implementation  
> > in both
> > syntaxes.
> 
> I have also just increased use of options such as wrap so this is not  
> a new "concept".
> 
> > To sum up I would like to see option 4 supported and implemented as  
> > you
> > described. The formatting would apply to (the result of) templates  
> > to be
> > consistent with the ;separator.
> 
> Yes, so I'd evaluate the entire expressions even if
> 
> $names:{$i$. <b>$it$</b>}$; format="upperCase"$
> 
> Here, the entire list of crap would be uppercased including the $i$  
> numbers.  Right?

Almost. Consider:

$names:{$i$. <b>$it$</b>}$; separator="v"; format="upperCase"$

Now I don't know why you'd want to have a letter as your separator,
but if you did, you would presumably want to distinguish that from:

$names:{$i$. <b>$it$</b>}$; separator="V"; format="upperCase"$

And so, format="upperCase" would need to apply to each $i$
separately. Although, could there be a difference with these:

$names:{$i$. <b>$it$</b>}$; separator="v"; format="upperCase"$
$names:{$i$. <b>$it$</b>}$; format="upperCase"; separator="v"$

Perhaps too surprising to have different behaviours; I think
the normal expectation is that such operations are commutative
in their sequence (reversible).

> > If there is a type mismatch (such as
> > $today;format="upperCase"$ where upperCase works on Strings and  
> > today is a
> > Date) then the empty string is returned (or perhaps an exception  
> > would be
> > better). Using a format string that doesn't exist as a method could  
> > also be
> > defined to return an empty string or throw an exception (not sure  
> > which is
> > best).
> 
> Hmm...I think perhaps that should reduce to simply $today$ if there  
> is no formatter...perhaps that allows you to remove a renderer w/o  
> breaking stuff?

Of course if 'today' is a long format date, format="upperCase"
does make sense.

If my templates are assuming a formatter/renderer, it may be
immensely useful to know that the renderer is missing for some
reason (for debugging purposes), so there should at least be
an option (I suggest the default case) to display an exception
string in the output, if a requested render format is not
available...

> > This handling of type mismatches and unsupported formats with option 4
> > syntax is preferred over the option 2 syntax. Option 2 would end up
> > potentially hiding properties. The person creating properties and  
> > the person
> > defining renderers would have to coordinate because they are  
> > sharing the
> > same namespace. Option 4 is a little more efficient since you know  
> > you are
> > done if you don't find a format method you don't have to go looking  
> > for a
> > property.
> 
> I think we'll need a severity/pendantic option for ST soon so you can  
> say what becomes an exception and what is ignored.

:)

One step ahead...

Thanks
Zen

-- 
Free Australia - www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.