I'm being frustrated a bit by an old TT2 "feature" that I used to think
was pretty cool. From Template::Manual::Variables, "Passing Parameters
and Returning Values":
> Named parameters may also be specified. These are automatically
collected
> into a single hash array which is passed by reference as the last
> parameter to the sub-routine.
I'm now employing 3rd-party (CPAN) code where a particular method
expects just a single key/value pair, and doesn't look to see if it gets
a hashref. So this:
[% obj.method( key => 'value' ) %]
is perl-ified as this:
$obj->method( { key => 'value'} );
when what I really need is this:
$obj->method( key => 'value' );
Of course, that's inherently the same as this:
$obj->method( 'key', 'value' );
so I could certainly work around the problem like this:
[% obj.method( 'key', 'value' ) %]
But that isn't intuitive and is subject to me (and my co-workers)
forgetting the caveat and having to debug this issue repeatedly. (It
took me an hour just now to re-discover the source of the problem...)
The "hash collection" is a nice shortcut for template writers not to
have to include the extra curlies, but it's a horrible trap for perl
programmers who may use the same method call in both perl and TT
contexts and try to use the same syntax out of habit. Would it be
reasonable to add a config option (HASH_COLLECTION => 0) to turn it off?
Or is it more reasonable to send a patch to the author of this
particular CPAN module to make this particular method attempt to deref
$_[0], knowing that there may be other as-yet-unidentified methods out
there in this and other packages that might need the same fix?
Thanks for your thoughts,
--Jason
_______________________________________________
templates mailing list
templates@template-toolkit.org
http://mail.template-toolkit.org/mailman/listinfo/templates
