AppleScript: The Definitive Guide, 2nd Edition

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 while 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 speak of 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 3, has its practical consequences. An AppleScript program that talks to a particular application can be severely hampered by the absence of that application. Even if you know all about BBEdit and how it extends the AppleScript language, you can't compile a script that talks to BBEdit unless you have BBEdit present on your machine at the time. If you send your friend a compiled script file that talks to BBEdit and your friend doesn't have BBEdit, your friend can't even read the script, let alone run it.

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. (You can see this consequence in action in Appendix A, where all my knowledge of AppleScript is ...