[stringtemplate-interest] Embedded loader problems

[Oliver Flege]

Hi,

> My original motivation for suggesting the StringTemplateManager was to
> minimize the effects of the breaking changes to StringTemplateGroup. That is
> to say StringTemplateManager was to be a refactoring/update of
> StringTemplateGroup - without static API members - that will eventually
> _replace_ StringTemplateGroup. It was to be functionally equivalent to the
> current StringTemplateGroup class.
> 
> You seem to be suggesting a StringTemplateManager class that manages
> StringTemplateGroup instances. I'm not sure that is needed. The current
> scheme with two types representing templates (StringTemplate) and template
> collection (StringTemplateGroup or perhaps StringTemplateManager in future)
> would seem to be sufficient.

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).

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
# 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



Oliver