[stringtemplate-interest] Embedded loader problems

[Terence Parr]

On Sep 1, 2006, at 9:32 AM, Micheal J wrote:

> Hi,
>
> [...]
>> // before the string template group can be used, the static
>> instance // needs to know which loader to use
>> StringTemplateGroup.RegisterGroupLoader(embeddedResourceGroupLoader);
>>
>> StringTemplateGroup stringTemplateGroup = new StringTemplateGroup(
>>     WebPageConstant.GROUP_TYPE_NAME,
>>     embeddedResourceTemplateLoader);
>>
>> StringTemplate stringTemplate =
>>     stringTemplateGroup.LookupTemplate(templateTypeName);
>
> I find the static members such as  
> StringTemplateGroup.RegisterGroupLoader()
> in the ST[#] library to be quite "ugly" actually. And they have  
> implications
> for use in a _truly_ multi-threaded environment (a real concern now  
> that
> dual-core and dual-cpu desktops are commonplace).

correct.  I really hated to do that but I had no other object that  
was managing things.  Your suggestion of a new StringTemplateManager  
class is probably a good idea.  After discussion, I'm happy to make  
this change for version 2.3.  Better to do it now than later breaking  
backward compatibility.

   The problem here is that we would then need to tell each group who  
manages it, which can cause some of the similar problems  That caused  
me to make a static member.   well, I think anyway.

> StringTemplateGroup should really be a self-contained manager for a
> collection of StringTemplate instances. With support extending the  
> managed
> domain to include the ST notion of a tree of related  
> StringTemplateGroups.

yep.

> In this scheme, RegisterGroupLoader() et al would be an instance  
> member on
> StringTemplateGroup and it's effect would be limited to the particular
> instance.

  so would we have to use this new StringTemplateManager thing to  
create new instances of groups?  It could be a very serious change to  
the functionality.

Ter