[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