[stringtemplate-interest] Embedded loader problems

[Terence Parr]

On Sep 3, 2006, at 11:54 PM, Oliver Flege wrote:
> First, I'd very much appreciate to get rid of the static members in  
> ST as the
> current implementation complicates setting up different group  
> hierarchies
> (unless you use different classloaders, which brings about problems  
> of its own).

Hi :)

In general, I thought that a single group loader would be okay  
because usually the directory structure indicates where load stuff so  
multiple loaders would not be necessary.  That said, I am  
uncomfortable with static methods and members.

> But then I do not think that it'd be sufficient to transform static  
> API members
> into non-static ones, as that would ignore the static fields  
> "nameToGroupMap" and
> "nameToInterfaceMap" in STG. The most appropriate solution I can  
> think of right
> now is the following:
>
> # StringTemplateRealm
> - collection of groups
> - completely independent of other realms (i.e., no static members)
> - maintains nameToGroupMap and nameToInterfaceMap
> - may have group loader assigned

   An interesting idea, but we would need to identify how often you  
need multiple loaders.

> # StringTemplateGroup
> - belongs to exactly one realm
> - collection of templates,
> - may refer to a super group
> - may implement interfaces
> - may have group loader assigned
> # StringTemplate
> - just as before
>
> As removing the static members would bring about an API change, I  
> would prefer to
> see that in ST 3.0 and to release the changes that have been made  
> so far as 2.3

Yes that makes sense as I am about ready to push this out.

Ter