[antlr-interest] Organization of complex template structures

Terence Parr parrt at cs.usfca.edu
Mon Dec 22 11:58:17 PST 2008


On Dec 20, 2008, at 7:45 AM, Mike Pagel wrote:

> Hi there,
>
> I am wondering how to best go about structuring complex sets of string
> templates. As I understand the current mechanisms, a template group is
> pretty much a class with its templates being the class methods. You  
> can
> build inheritance structures between groups and thereby overriding
> templates (the methods) and call super group (class) templates.

Contrary to some comments, that is exactly how i think of them.  
Polymorphism works etc...  template A in super invoking B (overridden  
in sub) invokes the sub.B

> This allows to build up some structure in terms of reusing basic
> templates and if required specialize certain pieces. But in the end,  
> you
> always call a template (method) that is part of or being inherited  
> by a
> specific leaf template group (class). Once the thread of control is
> within a template group there is no means to call templates in other
> groups, except for the groups which belong to inheritance line of the
> leaf group (if I'm not missing anything).

Correct.  No delegation model exists at this time, but multi- 
inheritance type thing can be done with a simple StringTemplateGroup  
multiplexor type thing.

> So far I find this limiting, e.g. if my model describes (Java) classes
> and I want to generate the class code. Then my leaf template group may
> be a "class.stg" with all kinds of templates like "generateMethods()"
> and "generateAttributes()". The implementation of those template now
> should invoke templates from a group "Methods.stg" and another group
> "Attributes.stg". (This example may not be pressing the issue but it's
> easy to follow.)

Usually generateAttributes  and similar will be grouped lgoically for  
one target. Why not put in a subclass.  You just override the abstract  
versions from class.stg.

> Now I cannot derive "Class.stg" from both other groups,

could invent a multiplexor ;)

> nor can I
> somehow call into these groups (like calling static members  
> functions of
> another class in code). What would be a good way to express this with
> the current mechanisms or is there actually a limitation?

Logically they belong together so might as well make them physically  
close (in same group file).

Ter



More information about the antlr-interest mailing list