Re: Concatenating scripts intelligently

Both solutions posted so far rely on having onInit be the one declaration section, but I actually have 11 different attributes, and at least four of them would make sense as declaration sections. They're also ordered among themselves. Here's a still incomplete but perhaps more representative list of attributes and their ordering:

preRestore
onRestore
onAttach
onInit
onAwaken
onChange

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

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]

Comment on Re: Concatenating scripts intelligently Download Code

Replies are listed 'Best First'.
Re^2: Concatenating scripts intelligently by ikegami (Patriarch) on May 09, 2006 at 22:53 UTC
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.	[reply] [d/l] [select]
Re^3: Concatenating scripts intelligently by sfink (Deacon) on May 09, 2006 at 23:11 UTC
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.	[reply]