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 <m...@mpagel.de> > To: antlr-inter...@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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to il-antlr-interest@googlegroups.com To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en -~----------~----~----~----~------~----~------~--~---
