Section 21.1. Pros and Cons of Scripting Additions

21.1. Pros and Cons of Scripting Additions

A scripting addition implements functionality along with terminology for accessing it. So does a scriptable application. So why use a scripting addition rather than a scriptable application? There are clearly some things that scripting additions do better than scriptable applications. An application must be running in order to be targeted; if it isn't running, it must be found, which may require user intervention, and it must be launched, which takes time. But a scripting addition, once installed, is always present. If a scripting addition puts up some interface, that interface appears to be part of whatever application is being targeted at that moment. An application's dictionary has to be loaded (using a tell block or a terms block) in order for its terminology to be accessible; a script addition's terminology is simply part of the language. For this reason, a scriptable application can't be used to define the terminology for an event handler. And communicating with an application is slower than calling a scripting addition command (though less so than formerly).

On the other hand, in some ways scripting additions are clearly a Bad Thing. There are some considerations of memory management, though these are too technical to describe here. A scripting addition is inconvenient, as in order to be available to a script, it must be not merely present on the user's machine (like a scriptable application) but installed in a particular location. Scripting additions can define coercions, but these cannot be documented in the dictionary. Finally, scripting additions invade the global AppleScript namespace, in ways that can be confusing and frustrating. A scripting addition may conflict with terminology the programmer would like to use; if a scripting addition was present when a script was compiled and absent when the script is run, the script may break, and the cause may be difficult to track down. (See Chapter 20 for examples and further discussion.)

For these reasons and others, Apple actively discourages, by word and deed, the proliferation of scripting additions. The words include official statements such as the following: "There are severe limitations to what you can do in the context of a scripting addition, and the system costs of managing large numbers of scripting additions are high." (The main limitation Apple refers to here is that a scripting addition cannot define any classes. The Apple document I'm quoting also says that scripting additions can't maintain state between calls, but this is no longer true.)

The deeds consist of Apple's own steady retreat from the use of scripting additions, replacing them with scriptable applications (which may be faceless background applications). On Mac OS 9, of the nine files present by default in the Scripting Additions folder, five are applications; under Mac OS X, of the seven files present in /System/Library/ScriptingAdditions, five are applications. (There's no particular reason why such an application should live in the ScriptingAdditions folder; it must still be launched and targeted like any other application. So the placement of these applications in this folder is a way of ensuring their presence while suggesting that they fulfill a utility function similar to a scripting addition.)

Nonetheless, scripting additions have a venerable history and don't show signs of going away anytime soon. In the early days of AppleScript, developers enthusiastically provided freeware or shareware scripting additions, which users have collected with something approaching the fervor with which HyperCard users once collected XCMDs. (A popular and definitive repository of scripting additions is http://www.osaxen.com.) Scripting additions are a convenient way to provide AppleScript with system-level abilities and powers of rapid calculation that it otherwise lacks. They are a fact of life with AppleScript.