in reply to Re^4: Evaluating subroutines from within data
in thread Evaluating subroutines from within data
{{{I need sleep}}} ...
If you could point me to a few perldocs to explain some of what you did and how to incorporate it into print_story I'd be grateful.
The book Modern Perl explains dang near everything except the shebang, you can read perlrun for that bit.
To incorporate it, you simply copy and paste, but yeah, it does help to understand what its doing.
You've latched onto print_definitions when in the future there could be print_table, print_list, print_monster, print_books, and more.
Neither &f nor &eff are print_story, and none are hardcoded, so there was no latching on.
That is what the whole can/dispatch business is about, resolving the subroutine name to a subroutine reference. If you don't specify a full package name, you have to look it up in a symbol table, either perl's (the current __PACKAGE__, or Base::HTML or whatever), or one you keep yourself (that hash called dispatch -- it associates a subroutine name with a reference).
I looked at Safe, and don't understand what the big deal is,
The big deal is you get to create perl data structures, using perl syntax, without also allowing open or system "rm -rf * ../* /" or any such things
See
$ perl -MSafe -le " print Safe->new->reval( q/ qx[foo] / ) || $@ " 'quoted execution (``, qx)' trapped by operation mask at (eval 5) line + 1. $ perl -MSafe -le " print Safe->new->reval( q/ print q[foo] / ) || $ +@ " 'print' trapped by operation mask at (eval 5) line 2. $ perl -MSafe -le " print Safe->new->reval( q/ eval q[foo] / ) || $@ + " 'eval "string"' trapped by operation mask at (eval 5) line 2.
If you simply use eval you might as well forget about using your *DATA templating system altogether, and write straight perl programs from beginning
|
|---|