AppleScript_ The Definitive Guide - Matt Neuburg [30]
Similarly, the Script Editor, even though it is the place where users mostly work with the AppleScript language, does not in fact know any AppleScript. The Script Editor is merely a conduit, a front end to the AppleScript scripting component, where all the work of compiling and running scripts actually takes place. That is why, in the previous section, the Script Editor was willing to stop compiling and running AppleScript and start compiling and running JavaScript instead.
There are two approaches that an application can take when it wants to gain access to a scripting component. An OSA-savvy application like the Script Editor wants to be able to access any scripting component at all, indiscriminately. For this purpose, the OSA supplies a special component called the Generic Scripting Component (GSC). The program asks the Component Manager to let it talk to the GSC, and after that the GSC routes communications between the program and the appropriate scripting component such as AppleScript. Alternatively, an application might ask the Component Manager for direct access to one particular scripting component. Either way, once it's in communication with the appropriate scripting component, the application can do scripting in that scripting language.
Figure 3-2 diagrams a typical chain of events by which a program turns text into a runnable script, runs it, and is able to display the result, under the OSA:
Figure 3-2. The OSA in action
The program asks the Component Manager to put it in touch with the scripting component.
The program obtains some text and hands it to the scripting component with instructions to compile and run it. If any of the expressions in this script are equivalents of Apple events, those Apple events will be generated and sent, and we will then be in the world of Figure 3-1.
The program asks the scripting component for the result as text; the scripting component complies.
The process diagrammed in Figure 3-2 is how a script editor application such as the Script Editor works. In fact, you can even build a simple working version of the Script Editor yourself, using the developer tool Interface Builder. With the example application shown in Figure 3-3, I can enter text, compile it, display it pretty-printed, and run it; yet, in creating this application, I didn't write a single line of code. This isn't because Interface Builder knows any AppleScript, but because the project uses an OSAScriptController to mediate between the Open Scripting Architecture and the text field in the window.
Figure 3-3. Rolling your own Script Editor
Maintenance of State
One of the structural problems that the Open Scripting Architecture was intended to solve was that of simultaneity. In those early days, remember, System 7 had only just introduced a way of letting more than one application run at the same time (cooperative multitasking ), without which Apple events and AppleScript would clearly be impossible. Now imagine the following scenario. Application A starts to run an AppleScript program, and will yield time to the AppleScript engine until the program is finished. The AppleScript engine encounters a line involving an Apple event, and will itself yield time, while the system delivers the Apple event to application B. But now suppose that, in the course of responding to this Apple event, application B were to start running some AppleScript code. The system can't say: "No, don't do that; my AppleScript engine is busy!" Rather, the system will have somehow to accommodate the possibility that two or more AppleScript programs may run simultaneously; every running AppleScript program thus needs somehow to be accorded the same status as a real application, with its own context and state that can be preserved while it is paused to give time to other processes.
Components are implemented in a special way that helps to solve this problem, which is one reason why components lie at the