[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