Seldaek/Dwoo — pull request #19 by themightychris (2014-04-18 22:20:17+00:00)
Title: prevent nested templatePlugin from overwriting parent instance

@Seldaek I know dwoo1 is end-of-life, but dwoo2 isn't suitable for me yet. I expect you won't want to merge any more pull requests but if you could comment on this a bit it would be very helpful as I wasn't able to discern the original intention behind appending templatePlugin function names with _$uuid

# Scenario
test.tpl:
```smarty
{load_templates test.sub1.tpl}

sub1 test

{sub1 "input1"}

{load_templates test.sub2.tpl}

sub2 test

{sub2 "input2"}
```
test.sub1.tpl:
```smarty
{template sub1 input}
sub1({$input})
{/template}
```
test.sub2.tpl:
```smarty
{load_templates test.sub1.tpl}

{template sub2 input}

sub2({$input}) -> {sub1 $input}

{/template}
```

# Problem
The above example fails on test.tpl's call to {sub1} with `Fatal error: Call to undefined function Dwoo_Plugin_sub1_535188f29fcdb()` because `{load_templates test.sub2.tpl}` copies an instance of sub1 with a different uuid from the cloned compiler back to the original compiler.

# Solution
The best solution I could find was to remove the _$uuid suffix from generated templatePlugin functions and prevent Compiler->addTemplatePlugin from overwriting an existing templatePlugin entry with one with a new UUID. Indexing template plugins by only their name in the templatePlugins array implies the names should be globally unique, so I couldn't make sense of why the function name needed to have the UUID appended. I kept the UUID logic in place for generating the scope though.

# Unanswered Question
- Why were template plugin function names appended during compilation in the first place and can you think of anything removing it would break?
- Is there a better way to approach this conflict?