Script objects are definitions that are only initialised when the code
containing them is run, so Outer only comes into being just before the
'set x to Outer' line.
Incorrect. The script object in the Outer slot is created when that
slot is initialised, i.e. when the script object whose slot that is
is created. And this script object, being the top-level script
object, is created at compile-time; ergo the script object in Outer
is also created at compile-time.
Short answer is: it's a bug (AppleScript has a lot of those),
presumably in how AppleScript binds variables at compile-time (done
for efficiency, but in a rather braindead manner that causes at least
one other bug I know of).
The simplest solution would be to redesign the code to avoid the
problem in the first place. Note that AppleScript tends to work a bit
more reliably when you don't stress it, and good design tends to
stress it a bit less than bad design does. While it's hard to judge
without seeing the original code, the example's code structure does
look rather odd, particularly with respect to encapsulation (or lack
thereof). From a good design point of view, it'd make more sense to
encapsulate theState and theScript within Outer:
on initialize()
script Inner
on showTheState()
display dialog "State " & theState
end showTheState
end script
set theScript to Inner
end initialize
end script
set x to Outer
set Outer's theState to 1
tell Outer to initialize()
tell Outer's theScript to showTheState()
set Outer's theState to 2
tell Outer's theScript to showTheState()
As well as being a more logical design it also happens to avoid the
OP's bug, which is nice.
