[antlr-interest] Organization of complex template structures

[Mike Pagel]

Thanks for your explanation. But even if I set aside the class/method 
analogy: how would I organize my templates then? From what you wrote I 
basically see that typically a template calls other templates within the 
same group. So how can I reuse a template for instance across different 
projects? Copy and paste it into the other project's template group 
file? Merge this and the other project's group files?

You are basically saying that all templates reside in a single group 
with inheritance being a feature to be used mainly for retargeting, but 
that's not practical for large scale projects. Other template engines 
like XPAND (open architectureware), T4 from MS DSL Tools, MD Workbench 
from Sodius, JET, ... *all* support splitting up your template project 
into trees of template files that can call each into each other. This 
way a template that knows how to serialize an attribute to something 
like "int i" can be used for class attributes as well as for method 
arguments, without the whole template zoo residing in a single group.

Another example: if a want to create the three elements of an MVP style 
application I will create at least three files, one for the business 
object model, one for the view and one for the presenter. Would I create 
three different template groups, one for each file? But how do those 
groups then share common templates? By (single) inheritance? Or would I 
have to put all templates into a single group? That's gonna be some file!

Is it really true that ST assumes most of the templates for a given 
project sit inside a single group?

Mike



Loring Craymer schrieb:
> 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
>>     
>
>
>
>       
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>