[stringtemplate-interest] ST4: New feature STGroup.unloadMore() ?

[Terence Parr]

lets change the old one. it's new enough very few to none will have to alter. it'll be in the changes notes so...
Ter
On May 17, 2011, at 9:47 AM, Udo Borkowski wrote:

>> i wonder if unload should unload the imports too?
> 
> A reason not to change unload (and why I suggested a new method) is compatibility. Things may become "incompatible" when users are explicitly calling "stGroup.importTemplates(g2)" in their code.
> 
> Personally I never used "stGroup.importTemplates(g2)" but always specify the imports in the group text. But I am using STGroupFile. People with a "STGroupDir" approach probably need the "importTemplates" method. For them the change would be significant (if they ever call "unload"). Then they need to call the "importTemplates" stuff after every unload.
> 
> Also not discarding the imports may have a performance advantage: imported groups don't need to be reloaded. Which is nice, as long the imports don't change.
> 
> I guess introducing a new "importMore()" is the "safer" way. However I personally would prefer to change the old "unload" method, if no one else complains.
> 
> 
> Udo
> 
> 
> 
> On 17.05.2011, at 18:13, Terence Parr wrote:
> 
>> i wonder if unload should unload the imports too?
>> Ter
>> On May 17, 2011, at 2:56 AM, Udo Borkowski wrote:
>> 
>>> Hi,
>>> 
>>> currently the STGroup method unload() 
>>> 
>>> 	"unloads" all templates and dictionaries but leave renderers, adaptors, and import relationships. 
>>> 
>>> Notice "import relationships" are not unloaded.
>>> 
>>> Other than renderers and adaptors the import relationship is often defined inside the group text and not by explicitly calling STGroup.importTemplates(…). This may lead to strange issues when the import list in the group text in the file is modified (especially when imports are removed/replaced) and stGroup.unload() is used to force next getInstanceOf to reload templates..
>>> 
>>> Example:
>>> 
>>> t.stg
>>> ==========
>>> import "g1.stg"
>>> 
>>> main() ::= <<
>>> v1-<f()>
>>> >>
>>> ==========
>>> 
>>> g1.stg
>>> ==========
>>> f() ::= "g1"
>>> ==========
>>> 
>>> g2.stg
>>> ==========
>>> f() ::= "g2"
>>> f2() ::= "f2 in g2"
>>> ==========
>>> 
>>> Calling t/main() correctly renders "g1".
>>> 
>>> Now we modify "t.stg" to
>>> ==========
>>> import "g2.stg"
>>> 
>>> main() ::= <<
>>> v2-<f()>;<f2()>
>>> >>
>>> ==========
>>> 
>>> and call unload() for that group.
>>> 
>>> We now render test/main() and get "v2-g1;f2", however I would have expected "v2-g2;f2".
>>> 
>>> This is because group t now holds the groups "g1" and "g2" in its "imports". "g1" was not removed. So when looking for template "f" it is first found in "g1" and used. When looking for "f2" it finds nothing in g1, but in g2. So both g1 and g2 are used for rendering.
>>> 
>>> What about introducing a new method unloadMore() that also unloads the import relationships?
>>> 
>>> I tried adding this to STGroup:
>>> 
>>> 	/**
>>> 	 * As {@link #unload()}, but also "unloads" the import relationships, i.e.
>>> 	 * already imported groups will be "re-imported".
>>> 	 */
>>> 	public synchronized void unloadMore() {
>>> 		unload();
>>> 		imports.clear();
>>> 	}
>>> 	
>>> Here a little test to check the result the new method STGroup.unloadMore:
>>> 
>>> 	@Test
>>> 	public void testUnloadMore() throws Exception {
>>> 		writeFile(tmpdir, "t.stg",
>>> 				"import \"g1.stg\"\n\nmain() ::= <<\nv1-<f()>\n>>");
>>> 		writeFile(tmpdir, "g1.stg", "f() ::= \"g1\"");
>>> 		writeFile(tmpdir, "g2.stg", "f() ::= \"g2\"\nf2() ::= \"f2\"\n");
>>> 		STGroup group = new org.stringtemplate.v4.STGroupFile(tmpdir + "/t.stg");
>>> 		ST st = group.getInstanceOf("main");
>>> 		Assert.assertEquals("v1-g1", st.render());
>>> 
>>> 		// Change the imports of group t.
>>> 		writeFile(tmpdir, "t.stg",
>>> 				"import \"g2.stg\"\n\nmain() ::= <<\nv2-<f()>;<f2()>\n>>");
>>> 		group.unloadMore(); // will also unload already imported groups
>>> 		st = group.getInstanceOf("main");
>>> 		Assert.assertEquals("v2-g2;f2", st.render());
>>> 	}
>>> 
>>> 
>>> Shall I add this to the sources? Got a better name than "unloadMore"?
>>> 
>>> Udo
>>> 
>>> 
>>> PS.: Here the corresponding test for STGroupUnload:
>>> 
>>> 	@Test
>>> 	public void testUnloadMore() throws Exception {
>>> 		writeFile(tmpdir, "t.stg",
>>> 				"import \"g1.stg\"\n\nmain() ::= <<\nv1-<f()>\n>>");
>>> 		writeFile(tmpdir, "g1.stg", "f() ::= \"g1\"");
>>> 		writeFile(tmpdir, "g2.stg", "f() ::= \"g2\"\nf2() ::= \"f2\"\n");
>>> 		STGroup group = new org.stringtemplate.v4.STGroupFile(tmpdir + "/t.stg");
>>> 		ST st = group.getInstanceOf("main");
>>> 		Assert.assertEquals("v1-g1", st.render());
>>> 
>>> 		// Change the imports of group t.
>>> 		writeFile(tmpdir, "t.stg",
>>> 				"import \"g2.stg\"\n\nmain() ::= <<\nv2-<f()>;<f2()>\n>>");
>>> 		group.unloadMore(); // will also unload already imported groups
>>> 		st = group.getInstanceOf("main");
>>> 		Assert.assertEquals("v2-g2;f2", st.render());
>>> 	}
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> stringtemplate-interest mailing list
>>> stringtemplate-interest at antlr.org
>>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20110517/fe3985b0/attachment-0001.html