[stringtemplate-interest] StringTemplate type proxies

[Rafael Chaves]

Funny, just joined the list and posted on a new thread on a similar
need I had (and the hack I used to work around it), jsu to find you
guys have been discussing the exact same issue.

Terence, if you always own the models you generate from, you will
never have this need. This issue is a killer for those using complex
models implemented by others.

Cheers,

Rafael

> From: Terence Parr [mailto:parrt at cs.usfca.edu]
> Sent: Monday, December 13, 2010 9:08 PM
> To: Sam Harwell
> Cc: 'stringtemplate-interest'
> Subject: Re: [stringtemplate-interest] StringTemplate type proxies
>
>
>
> Hi Sam, I'm still trying to figure out how I get away without this.  I'm
> leary of adding features when I haven't ever needed them.
>
>
>
> Ter
>
> On Dec 13, 2010, at 2:55 PM, Sam Harwell wrote:
>
> I implemented this in the C# port of ST, and submitted it in changelist
> 7307. I also updated the way items are registered so registrations apply to
> derived types and interface implementations. Here is the order in which the
> search is performed (the * indicates “until null”):
>
>
>
> 1.       Search current template
>
> 2.       Search enclosing template*
>
> 3.       Search group
>
> 4.       Search super group*
>
>
>
> Here is the order in which a match for type T is found. This check is
> performed at each step of the above process until a match is found (with
> some key optimizations in place to keep it from going slow).
>
>
>
> 1.       Check for a registration for T (exact match).
>
> 2.       Check each registration K at the current level – if T is derived
> from class K or implements interface K, then it is a candidate. If this step
> reveals candidates,
>
> a.       If there is exactly one candidate, it is chosen as a weak match and
> the process is complete.
>
> b.      For each pair of candidates T1!=T2, if T2 is derived from class T1
> or implements interface T1, then T2 is a strictly stronger match and T1 is
> removed from the set of candidates.
>
> c.       The filtering process always leaves 1 or more candidates. If only 1
> candidate remains, it is chosen as the weak match and the process is
> complete.
>
> d.      If >1 candidates remain, an AmbiguousMatchException is thrown.
>
>
>
> From: stringtemplate-interest-bounces at antlr.org [mailto:stringtemplate-interest-bounces at antlr.org] On
> Behalf Of Sam Harwell
> Sent: Sunday, December 12, 2010 9:41 PM
> To: stringtemplate-interest
> Subject: [stringtemplate-interest] StringTemplate type proxies
>
>
>
> I recently started using StringTemplate for a significant code generation
> project. I’m quite happy with the way things are progressing, but I’m
> noticing there are several times where I have to add a new property to my
> code objects just so StringTemplate can produce the desired output. In a
> manner similar to attribute renderers, I believe the addition of type
> proxies would be extremely beneficial. Suppose the user registers a type
> proxy for type T. The type proxy exposes the following method:
>
>
>
> object createProxy(object value);
>
>
>
> Whenever an attribute resolves to a value of type T, the proxy’s
> createProxy() method is called. Attributes on the object are resolved
> against the value returned by the proxy.
>
>
>
> Any thoughts on this?
>
>
>
> Thanks,
>
> Sam
>