[stringtemplate-interest] Group Syntax extension for ModelAdapter and Renderer

[Terence Parr]

On Jun 30, 2011, at 1:57 PM, Udo Borkowski wrote:

>> ... I don't like String having two renderers in system at once. BUT, we currently allow you to set renderers PER group so what does that mean?  For non-imported groups, it's obvious.  For imports, any renderer set on import group is ignored even when using import template.  I guess I'm ok with that. Set the renderer on the main group you use (or all to be sure).  I look at import groups as "helpers" that should give me templates and nothing else.
> 
> This is a very nice summary of your objectives and your intentions. However ST4 as it is today does not really reflect this. 
> 
> I think the main problem is associating renderers/adaptors with STGroups. From what you write I think you are thinking of renderers/adapters more of "language extensions" (or "system extensions") rather than "Group extensions". This would be better reflected by moving the whole renderer/adapter stuff to the "Interpreter" (something already suggested in this thread). This way it is obvious there will be no "two renderers for String in the system".

ah! you are so right! it was a leftover from v3 that had no interp really.

> Attaching the renderers/adaptors to the interpreter would also get rid of the question what "renderers of imported templates" mean (as there aren't any). This would also mean one would not need to set the "renderers of the main groups" but just to the interpreter, also avoiding this "in-symmetry" regarding groups. (BTW: This change will break existing code, as STGroup no longer provides the "register…" method. Also the Interpreter would become more prominent in this solution etc.).
> 
> On the other hand I personally would prefer to stick to the "per group" registration of renderers/adapters and add the "look first in native group" feature. This would mean there could be more than one renderer per class (e.g. for String). However I don't have a problem with this as long it is clear what renderer is used. The main reason why I support this is probably the way I look at groups. Rather than looking at imported groups as "helpers" groups are for me the units of modularization in ST4. I create groups that serve a certain purpose and can be used "on their own". I later want to use them in other groups, simply be importing them and calling their templates. I would not like to do more (like merging various String renderer implementations) as this makes the reuse harder and more error-prone. (BTW: this change is compatible with existing code, just adds some more options)
> 
> So I see two options regarding renderers/adapters of imported groups here:
> 1) move the renderer/adapter stuff from STGroup to Interpreter, or
> 2) Implement the "look first in native group" for renderers/adapters (my favorite)

how about ONLY look in native group?  That is even more clear I think and was sort of my original thought/expectation on this.

> 
>> Udo: can you live with making one uber-string-renderer?
> 
> Actually no, as this does not really solves the problem I tried to point out. The example I brought up was just an example to illustrate the situation. Of cause one could come up with solutions that work around the issue, but this was not really my point. 
> 
> My main point was asking to support renderers in imported groups (without changing the root groups). This is not directly related to String renderers. E.g. if I have a general purpose group "XMLUtil" dealing with XML I want to add a renderer(/adapter) for "org.w3c.dom.Node" to the "XMLUtil" group. The "root groups" don't need to know about this. I may even have different groups using different adapters/renderers of "Node". This leads to a better system structure, with all these things like "information hiding", "separation of concern", "modularization", "encapsulation", …
> 
> ----------
> 
>> One of the Sams suggested a single renderer for strings that knows more escapes. I think that is a fine solution since we are really saying we need to render strings in both cases. Why not group together:
>> 
>> <s; format="javadoc-escape">
> 
> 
> When you talk about "group together" do you mean the stuff discussed in "[stringtemplate-interest] [ST4] How to apply multiple "format"s to an expression?" http://www.antlr.org/pipermail/stringtemplate-interest/2011-February/003216.html ?

Just meant building combining code from two renderers into one.

Ter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20110630/1eb73d00/attachment.html