AppleScript_ The Definitive Guide - Matt Neuburg [40]
When an instance of the AppleScript scripting component comes into existence, it loads any scripting additions found in any of several locations , namely /System/Library/ScriptingAdditions and the corresponding folders in /Library and ~/Library. (On Mac OS 9 and before, there is just one location, the Scripting Additions folder of the System Folder. Observe the lack of a space in the Mac OS X folder name ScriptingAdditions; the tale of how that happened is gory and not to be recounted here, and in any case it's too late now to change it.) If a script depends upon a scripting addition, it is up to the end user to install that scripting addition first on any machine where that script is to run. Unfortunately, end users can't be relied upon to do this, which makes it hard to share your scripts with other users if your scripts depend upon any third-party scripting additions . Fortunately, an applet bundle or an AppleScript Studio application will also load scripting additions contained within its own bundle, an innovation that nicely solves the problem.
Tiger comes with just two scripting additions installed by default: StandardAdditions and Digital Hub Scripting . Some earlier systems came with half a dozen scripting additions from Apple, which was confusing; the StandardAdditions osax incorporates most of the functionality of these earlier files.
Communication between a running script and a scripting addition takes place by way of Apple events, just as for a scriptable application. But a scripting addition is not an application, so it doesn't have to be running in order for a script to talk to it. There is also an important linguistic difference to the AppleScript programmer between a scripting addition and a scriptable application, having to do with how the terminology is resolved. To talk to a scriptable application using terminology defined in that application's dictionary , a script must explicitly target that application. But the terminology defined in a scripting addition's dictionary is simply present as part of the language, without the programmer's targeting anything at all. (In fact, you can't target a scripting addition.) This sounds cool, but in practice over the years it has become something of a nightmare, because the more scripting additions you've got installed, the more likely it is that vocabulary terms implemented in a scripting addition will clash with terms you'd like to use, with terms of another scripting addition, with terms of some scriptable application, or even with the core AppleScript language. (This point is taken up again in detail in Chapter 20.)
Dictionary
AppleScript is a little language. It is also an extensible language. The purpose of AppleScript is to communicate with scriptable applications by means of Apple events; each such application can extend the terminology of the language in its own way, defining a repertory of Apple events to which it is prepared to respond, along with the English-like AppleScript terms to which these Apple events and their various parts correspond. To be scriptable with AppleScript, the application must publish information about this repertory. The mechanism by which this publication takes place is a resource called a dictionary.
The AppleScript scripting component uses the dictionary when compiling and decompiling a script, for two purposes:
To confirm, at compile time, that the English-like terms used by the AppleScript programmer are legal
To translate, at compile time and at decompile time, between English-like terms and Apple event structures
Not only does a scriptable application have a dictionary; a scripting addition does too, and for the very same reasons. (In fact, AppleScript itself has a dictionary.)
Dictionary Formats
A dictionary may be expressed in any of three formats :
The 'aete ' resource
The 'aete' resource is present in scriptable applications in Mac OS 9 and before, and