Second release, and I now have everything I need for doing basic file construction in Padre.
I've got whitespace control in tags via explicit chomping such as [%- foo -%].
The basic recursive expression resolver is done for things like [% hashkey.1.methodname %] and works for arrays, hashes and objects. The resolver also now has the same kind of exception-tolerant, warning-squashing behaviour that Template Toolkit does.
And finally I've added the three simplest and most basic control structures, IF, ELSE and UNLESS.
All this cost about an extra 15-20k of RAM, for around 40kb total so far (with maybe 5-10kb of recoverable fat). But note that I don't yet have support for files, so there's some fairly chunky costs still to come (especially because I can't use things like File::Spec).
Now this is where things get a little more interesting, because the real skill in creating most ::Tiny modules are about selecting the really critical compromises.
For Template::Tiny, the key compromise looks to be stash immutability. If you can be sure that the stash will never mutate (and if you don't allow things to collide with the stash names) you no longer need to process the template elements in order from top to bottom. Which means you don't need to compile the template into intermediate Perl code, the templates won't be turing complete, and you can just evaluate it directly from template to finished text via a series of regex passes.
Of course, now I have some other problems, such as doing a fairly complex and recursive regex matching exercise using only features available in Perl 5.005 (and in very little code, and without resorting to things like Text::Balanced that are 1000 lines of code).
So if you have some serious regex-fu, I'd love some help because my other option is trawling around in Text::Balanced-type Damiancode for clues :)
You've mentioned in your documentation that "anything beyond this is out of scope". Without filters and loops, it might be OK for Padre, but I doubt anyone else would really be in a position to use it (or course, it would be severely hampered without includes, too).
Re:No Loops or filters?
Alias on 2009-12-08T16:18:19
It's out of scope of the implementation that is currently completed, which is indeed enough to solve my immediate problem in Padre.
But I've still got 60k left in my memory budget to buy features with. If we can find a way to spend it wisely enough, then we should get through all the features that are more widely agreed to be useful in the situations where full TT is too large.
