3.8. Scripting Addition

AppleScript is a little language, and at a very early stage it was felt to be a bit too little. An architecture was therefore devised whereby Apple, as well as third-party developers, could extend the language by means of scripting additions. A scripting addition is a code library, typically written in a compiled lower-level language such as C, whose purpose is usually to endow AppleScript with some functionality that can be implemented in this lower-level language (possibly by calling into the Macintosh Toolbox) but is otherwise missing from AppleScript itself. On Mac OS 9 and before, a scripting addition is a resource file of type 'osax'; on Mac OS X it can also be a bundle with extension .osax. Therefore it is common parlance to refer to a scripting addition as an osax (official plural, osaxen).

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.)