20.1 Pros and Cons of Scripting Additions

In certain ways, scripting additions are clearly a Bad Thing, and Apple actively discourages them. As Apple puts it, "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 is that a scripting addition cannot define any classes.^[1] The system costs involve the global AppleScript namespace—we have already talked, in Chapter 19, about the terminology problems that scripting additions can cause—and certain technical considerations of memory management.

^[1] A scripting addition can define events (commands). It can define pseudo-classes; see Section 19.3.6. It can also define coercions; this is not terribly common, but Jon's Commands defines some—see http://www.seanet.com/~jonpugh/. The Apple document I'm quoting here also says that scripting additions can't maintain state between calls, but this is no longer true.

Apple has tried to lead users away from scripting additions, in part through example, by installing faceless background applications in the same folder where the scripting additions live. 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. Such applications must be targeted explicitly; their vocabulary does not appear automatically as part of the AppleScript language. But applications don't suffer from any of the disadvantages of scripting additions, and as long as they are present on every machine, the commands they contain are universal.

On the other hand, there are 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 launched, which takes time. A scripting addition, on the other hand, 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. And communicating with an application is slower than calling a scripting addition command (though less so than formerly).

Scripting additions have a venerable history. Many generous developers have provided freeware or shareware scripting additions, and users have collected these 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.

So it doesn't seem that scripting additions will be going away any time soon. One could argue that they aren't a very good idea, but they are a fact of life when you're using AppleScript.