AppleScript_ The Definitive Guide - Matt Neuburg [31]
You can readily see how this architecture solves the simultaneity problem. Suppose we have two different applications, each of which gets a connection to the AppleScript scripting component and asks it to compile and execute a script. The AppleScript component does not get all flustered and say, "Oh, gosh, two different programs are trying to get me to do two different things at once!" Rather, there are in effect at that moment two different AppleScript component instances—the one that the first application is talking to and the one that the second application is talking to. Each application asks its own instance of the AppleScript component to compile and execute its script, and there is no conflict or confusion at all.
One important and characteristic consequence of this architecture is that each instance of a component has a memory of its own. When paused, it remembers what it was doing. We say that a component can maintain state. When it is handed a script to compile, it remembers the script. After compilation, it remembers the compiled version of the script. After the script is executed, it remembers the result. And this is true of each individual instance of the component, separately; state is maintained individually for each instance. The component to which a program gets a connection is like an instance in the world of object-oriented programming (that's why it's called an instance). In terms of our analogy, each little AppleScript universe remembers what goes on in it. Thus an application is able to return again and again to its same AppleScript universe and refer back to things that happened earlier. Multiple applications can do this at the same time, and yet the AppleScript scripting component maintains state for each of them without getting confused at some global level, because it isn't operating at a global level. It's operating at a local level—local to the application that summoned it.
You can see this happening in Figure 3-2. Recall that from the calling application's point of view, there are two separate steps: first the application hands the AppleScript scripting component some text to be compiled and executed; then, after execution is completed, the application asks for the result. The fact that the application can come back a second time and ask for the result of an execution that took place earlier is an example of the AppleScript scripting component's ability to maintain state. Similarly, although this does not appear in Figure 3-2, it would be possible to introduce a third step: we could have our application initially hand the text to the AppleScript component and ask it to compile it, but not (at that time) to execute it. Our application could then later return to the AppleScript component and say: "Hey, remember that script I had you compile a little while ago? Now I'd like you to execute it." And this will work, because the AppleScript component remembers the compiled version of the script.
Back in the world of System 7, on a computer where memory was tight and under a system architecture where context switching was slow, this approach was downright elegant. Virtually no information passes between the calling application and the AppleScript component instance unless the calling application