[antlr-interest] Organization of complex template structures

Loring Craymer lgcraymer at yahoo.com
Sat Dec 20 23:17:42 PST 2008


Your understanding is flawed--template groups are not classes, nor are
templates methods.  Treating them as such is likely to cause you
grief.  Think rather that template groups are a convenience for
argument checking against a template interface.  That way, changing
template groups makes it possible to switch from, say, generating Java
code to C# just by switching template groups.  Template groups are a
mechanism for retargeting.  Switching individual template groups within
an application while leaving others unchanged is not a common usage
pattern.

Instead of thinking of templates as methods, take a
simpler view:  arguments fill "holes" in templates and the arguments
should be thought of in "instantiated" form.  Thinking of arguments as
dynamically invoked methods misses an important level of abstraction: 
argument evaluation is independent of template evaluation and is
side-effect free.  [It is possible to implement side-effects as the
result of evaluation through reflection, but the results are
unpredictable.  Do not do this!]

It is possible to invoke other
templates in the same group from within a template, but you should see
this as a macro invocation, and the facility as a convenience to allow
factoring.  Almost always, the invoked template is local to the
template group (not declared in the interface).  Such invocations tend
to be uncommon.

--Loring




----- Original Message ----
> From: Mike Pagel <mike at mpagel.de>
> To: antlr-interest at antlr.org
> Sent: Saturday, December 20, 2008 7:45:01 AM
> Subject: [antlr-interest] Organization of complex template structures
> 
> 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.
> 
> 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).
> 
> 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.)
> 
> Now I cannot derive "Class.stg" from both other groups, 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?
> 
> Thanks a lot,
> Mike
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: 
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address



      


More information about the antlr-interest mailing list