use Script ();

# Data extracted from XML.
my %snippets = (
   onInit   => 'use strict; my $x=2;',
   onAwaken => 'print ++$y;',
);

my $script = Script->new(\%snippets);
$script->onInit();
$script->onAwaken();
[download]

Global symbol "$y" requires explicit package name in onAwaken.
[download]

If so, use the following module:

Update:

• Made it easier to dispatch by creating the Script class.
• Handlers can now receive arguments.
• Handlers can now return a value.

Yes, I think that does exactly what I want! Thanks for really diving into it!

I actually want it to output something like

Global symbol "$y" requires explicit package name in onAwaken snippet at somefile.xml line 42.

...but that requires external information (the file, line of each attribute) that I didn't mention before, and it's a straightforward addition to your script.

I figured you'd want something like that. You'll probably want to handle warnings too. local $SIG{__WARN__} will help you do that.

An improvement I see is to optimize the line count to only count from the point where last count left off.

( For the reason I explained here, this node doesn't help the OP. This one does. )

Would the following do the trick?

# Info extracted from
#    <script onInit='use strict; my $x; my $y;'
#            onAwaken='print ++$x'
#            onAwaken='print ++$y'/>
#
my $onInit   = 'use strict; my $x; my $y;';
my $onAwaken = 'print ++$x';
my $onSleep  = 'print ++$y';

# Compile code
my $code = "package Sandbox;"
$code .= "$onInit;";
$code .= "sub onAwaken { $onAwaken }";
$code .= "sub onSleep { $onSleep }";
eval $code;

# Dispatch an event
Sandbox->onAwaken() if Sandbox->can('onAwaken');
[download]

The above can easily be expanded to handle multiple documents by generating incremental package names.

That's very close to just having a separate "declare" section. The OP can do that too.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

my $init = eval <<EOI;
sub {
  $INIT_CODE;

  my \$sub = eval q(sub { $AWAKEN_CODE });
  die "bad onAwaken: \$@" if \$@;
  \$sub;
}
EOI
die "bad onInit: $@" if $@;
my $awaken = $init->();

...

# and later onAwaken...
$awaken->();
[download]

update: or if several attributes as onAwaken can exist:

my $init = eval <<EOI;
sub {
  $INIT_CODE;

  my \$sub = eval 'sub { \$_[1] }';
  die "bad \$_[0] code: \$@" if \$@;
  \$sub;
}
EOI
die "bad onInit: $@" if $@;

my $awaken = $init->(onAwaken =>$AWAKEN_CODE);
my $foo = $init->(onFoo => $FOO_CODE);
...

# and later onAwaken...
$awaken->();

# and onFoo;
$foo->();
[download]

• preRestore
• onRestore
• onAttach
• onInit
• onAwaken
• onChange

Update: Just to be explicit, here's an example:

  <script preRestore='use strict'
          onRestore='my $pos = [ 10, 20 ]'
          onInit='my ($x, $y) = @$pos;'
          onChange='$x += 1; $y += 2; $pos = [ $x, $y ]'
          />
[download]

Both solutions posted so far rely on having onInit be the one declaration section,

Not at all. Concatenate them! ( Oh I see, they're suppose to be called at different times. That means while the compilation of onRestore's snippet has to be done at the same time as the compilation preRestore's snippet's, their execution occur at different times. Truly my solution does not do that. )

Oh, and I like the idea of sandboxing everything into a package -- but I'm already doing that

Despite the name, my code isn't sandboxed. It can freely modify other packages. You'd probably have to use Safe to truly sandbox some code.

Sorry, I was using "sandboxing" loosely. It's still useful, especially since when I delete one of these script tag nodes, I can use Symbol.pm to delete its package and get rid of most of what it did in the (global) perl interpreter. If the script puts anything into another package, then it will survive indefinitely -- but that is usually more of a feature than a drawback, since it can be convenient to write a script that, say, rewrites the menu system permanently when you run it. I'd rather give script writers loaded bazookas and maps showing where their feet are, than try to enforce limitations externally.

Having a unique package is good for other things too, but I don't suppose it's relevant to this thread.