Extensibility and Its Perils

As part and parcel of its power to communicate with other applications, AppleScript concedes to those applications an ability to extend the language. Such linguistic extensions appear temporarily to be part of AppleScript, only for just so long as your program is talking to the application that provides them. We thus have a language that grows and shrinks and mutates depending on what application it is talking to. For example, AppleScript itself knows nothing of a disk or a folder, but the Finder does. So as long as your AppleScript code is talking to the Finder, it can talk about a disk or a folder. The moment it is no longer talking to the Finder, it can’t.

This architecture, as we saw in Chapter 4, has its practical consequences. An AppleScript program that talks to a particular application becomes something of a nonentity in the absence of that application. If you send your friend a compiled script file that talks to BBEdit and your friend doesn’t have BBEdit, the result isn’t just that your friend can’t run the script—your friend can’t even read the script. Similarly, even if you know all about BBEdit and how it extends the AppleScript language, you can’t write and compile any AppleScript code that talks to BBEdit unless you have BBEdit present on your machine at the time.

For the programmer, the main consequence of AppleScript’s extensibility is that it is not one language but many—as many as there are applications to which you might wish to speak. ...

Get AppleScript: The Definitive Guide now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.