4.2. 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 manyas 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 as nothing compared to my ignorance of how to talk to one particular application.) Thus the AppleScript programmer, no matter how expert, remains something of a perpetual neophyte. Even the most AppleScript-savvy programmer I know has said to me, "I hate trying to figure out the scripting quirks of every app." AppleScript thus displays some tendency to discourage its most devoted users from doing the very thing it was intended to do.

Perhaps even worse than all of this is the everlasting conflict between the various namespaces: terms in a target application, terms in scripting additions, terms in AppleScript itself, and terms you make up for your own use. You just never know when you'll try to say something in AppleScript and it will fail at compile time or at runtime with a mysterious error message, all because an already defined term of whose existence you had no inkling or warning has stepped on your toes. I've mentioned this before ("Dictionary" in Chapter 3) and I'll talk at length about it again ("Terminology Clash" in Chapter 20).