[stringtemplate-interest] Attribute definitions, Group files and Templates.

[Zenaan Harkness]

On Tue, Oct 13, 2009 at 03:28:59PM +1030, Barrie Treloar wrote:
> The other thread about cleaning up ST made me check Jira for one of
> the things I wanted while working with ST.
> 
> I wanted to use a directory for my TemplateGroup instead of a file.
> As the size of my templates would make the group file massive and unwieldy.
> 
> I think the only reason I wanted a group was so I could get attribute
> definitions in my templates.
> If the new version of ST will allow me to do this for template files
> then I think I dont need TemplateGroup as a directory instead of a
> file.
> Can anyone see the values of having TemplateGroups as a directory then?

I rather like the structured Java-like approach:

   -  Directories correspond to java 'Packages', or "ST Packages"
      ie groups of ST TemplateGroups.
   -  Files correspond to classes, ie ST TemplateGroup files.
   -  Individual ST templates can be in a single file,
      BUT, for uniformity (ala Java), should still be a TemplateGroup.


   -  Next, TemplateGroups (just Group perhaps??), have an inheritance
      hierarchy ("extends", like Java classes).
   -  Multiple inheritance, would help big time for me.
      -  I have a "lib" ST group
      -  I have a language specific group (eg. Java, C#), sort of
         specialized 'lib' groups
      -  I have specific lower level/ operational groups which often
         need to inherit templates from different parent lines.

   -  Ie, I am using the TemplateGroup to bring sanity to the number and
      structure of templates.
   -  Without multiple inheritance, I am required to do some really
      hacky temporary file munging, to ensure that all groups I need
      ultimately form a single-inheritance hierarchy.

   -  A good language (eg. Java, ST), provides facilities to competantly
      manage complexity.
   -  Current versions of ST do not provide adequate complexity
      management facilities for larger projects.
   -  So, whether MultipleInheritance, or something else (eg. "mixin"
      pattern is the more robust way than "inheritance" pattern to
      componentize, where possible, at least when it comes to
      programming languages), another tool within ST for complexity
      management is required.

   -  It is my belief, that because ST is a declarative generative
      language, multiple-inheritance should not pose anywhere near the
      fine grained difficulties that we see for example in C++ MI.


So, directories are a fine and natural (given current and foreseeable
OSes) tool for grouping of files, and therefore a useful tool for
complexity management, which tool we _are_ currently using in ST.

To have TemplateGroups _be_ a directory, is comparable (comparison with
Java) to having a class of functions/methods, _be_ a directory - ie
splitting out each method into its own file, and having all those files
in a directory, and the directory be the java Class.

Of course, historically, it made sense - ST was built piece by piece,
and started out with much less features than it has now. thankfully,
despite feature growth,

   --== ST remains the only template engine to
        consistently separate view from model. ==--

And THAT is quite an achievement, for which we can thank Ter's rigorous
analysis in the first instance, written paper, and ongoing education and
commitment to this foundation principle (now of course supported by we
the ST community).

I have been convinced for some years now, since I first studied and
began my own ST journey, that ST's day is yet to truly begin. And I
think that with a spec :), the cleanup now in progress (thanks Ter), and
just a few little extra features (including in particular something akin
to multiple inheritance/ one more complexity management tool), then ST
has the potential to be the foundation of an amazing renaissance in
programming/ software development. Time will tell of course :)

cheers
zen

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.