fill_in_string breaks "new package every time" behavior [rt.cpan.org #51473]

[mschout]

https://rt.cpan.org/Ticket/Display.html?id=51473

This program:

  my $template = '{ $foo } and { $bar } in { __PACKAGE__ }' . "\n";

  print Text::Template::fill_in_string(
    $template,
    HASH => { foo => \10, bar => \20 },
  );

  print Text::Template::fill_in_string(
    $template,
    HASH => { foo => \30 },
  );

  print Text::Template::fill_in_string(
    $template,
    PACKAGE => 'Specified',
    HASH    => { foo => \30 },
  );

...produces this result...

  10 and 20 in main
  30 and 20 in main
  30 and  in Specified

This is because &fill_in_string will default to using the caller's
package instead of an autogenerated package instead of using the normal
procedure for package choice/generation in &fill_in.  I don't know why
it does that; possibly to deal with the extra stack frame it introduces?

Is that the case?

In the meantime, I can use fill_this_in, I think.

-- 
rjbs

[mschout]

Hi Ricardo.

I realize this reply is really late (as you reported this in 2009), but I have obtained maintainership on Text::Template and have been slowly working through old bug reports.

I'm not sure why MJD did this in fill_in_string(), but he did create a test case that depends on the caller package being used (t/08-exported.t), so this apparently was done intentionally. It does seem odd to me, but given the age of this module, and how far "up river" this module is, I'm more than hesitant to change this behavior at the risk of breaking a lot of deployed code. The test case mentions "Donald Greer Jr" as the person reporting this issue (and presumably responsible for the suggestion to use caller()). But I have no contact info for this person. MJD didn't have an open repository, and didn't use a public bug tracker, so I do not have any insight to go on. I don't think MJD is active in the perl community any longer, as obtaining comaint took quite a bit of time :).

Maybe a good compromise would be to add some kind of parameter to fill_in_string() telling it to use a generated package instead of using the caller (by default)?

On Thu Nov 12 09:31:39 2009, RJBS wrote:

This program:

my $template = '{ $foo } and { $bar } in { PACKAGE }' . "\n";

print Text::Template::fill_in_string( $template, HASH => { foo => \10, bar => \20 }, );

print Text::Template::fill_in_string( $template, HASH => { foo => \30 }, );

print Text::Template::fill_in_string( $template, PACKAGE => 'Specified', HASH => { foo => \30 }, );

...produces this result...

10 and 20 in main 30 and 20 in main 30 and in Specified

This is because &fill_in_string will default to using the caller's package instead of an autogenerated package instead of using the normal procedure for package choice/generation in &fill_in. I don't know why it does that; possibly to deal with the extra stack frame it introduces?

Is that the case?

In the meantime, I can use fill_this_in, I think.

-- Regards, Michael Schout