In the course of translating the Template Toolkit into Python, I accumulated
a small(ish) list of issues I noticed with the Perl version.  Most are
minor--documentation issues and the like--but a few are more serious.
Here's one of them, from t/constants.t:

ok( $text =~ /"back is " . '#ffffff'/, 'col.back folded' );

The problem here is that the matching is performed in list context, so if it
fails, ok receives only a single argument, the string 'col.back folded',
which is true.  So, this test can never fail.  The solution is either to add
a $$ prototype to Template::Test::ok or ensure that tests that involve
pattern matches are always performed in scalar context.  I think prototypes
aren't generally a good idea, so I'd go for the latter approach.

Another issue deals with PERL/RAWPERL blocks.  Consider this template:

[% FOR x IN [ 1, 2, 3 ] %]
  [% PERL %]
    $list = 1;
  [% END %]
[% END %]

This results in the strange message "undef error - Can't call method
"get_next" without a package or object reference", thrown because $list is a
variable used by the generated code for the FOR loop.  I'd like to propose
that generated code declare only lexical variables whose names are prefixed
with an underscore, that class of names being henceforth reserved for use by
the TT.  (Variables intended to be used by user code, such as $stash,
$context, et al, would of course be exempt.)  That way, we could guarantee
to users that errors of the above type could never occur if they don't
intrude on the forbidden namespace.

I'd be happy to work up some patches, but I'm not clear on the appropriate
submission procedure.


--Sean
_______________________________________________
templates mailing list
[email protected]
http://mail.template-toolkit.org/mailman/listinfo/templates

Reply via email to