• Choose a category
• All
• Classic-Fiction

end tell

This might lead you to believe that the AppleScript compiler will use an application's dictionary to confirm that what you're saying is valid. Don't believe that. It is all too easy to form a nonsensical expression and get it past the compiler—which will then form a nonsensical Apple event, which will be sent to the application at runtime. In general, you should not expect compilation to serve as a "sanity check."

For example, the dictionary describes certain definite relationships between particular terms—this property is a property of this class, this element is an element of this class, this name is a class, this name is a property—but AppleScript largely ignores such information. As far as the compiler is concerned, property and element names are not encapsulated with respect to their class, and property names and class names are not distinguished. The result is a namespace mess; indeed, this is one reason why terminology clashes can so easily occur.

The examples that follow illustrate the staggering willingness of the compiler to form a nonsensical Apple event. When you send such an Apple event, there is no hope that any good can come of it. It's up to the target application to notice the problem and return an error message.

For instance:

tell application "Finder" to get column 1 of desktop

That's total nonsense; column is an element of the list view options class, not of the desktop. But the compiler doesn't care; it can see the dictionary, but it doesn't draw even such elementary, straightforward conclusions from it. So that code compiles. Of course there's an error at runtime.

Here we use a class name where a property name is expected:

tell application "Finder" to eject the item of file 1

The Finder's dictionary makes it clear that item isn't a property of file, and that it isn't a property name but a class name. But the compiler ignores such matters.

Here we use a property name where a class name is expected:

tell application "Finder"

tell folder 1

make new extension hidden

end tell

end tell

The make command expects a class after new. But extension hidden isn't a class; it's a property. The code compiles anyway.

In this example, we seem to be using a noun as a verb; yet the compiler accepts it:

tell application "Finder" to folder the item

It probably looks to you as if AppleScript has treated folder as a verb; but in fact AppleScript is supplying get, as it typically does if the verb is missing. AppleScript is parsing your words like this:

tell application "Finder" to get folder index item

It thinks you're asking for a folder by index (e.g., folder 1), except that you've put the class name item as your index instead of an integer value. The fact that a class name is not a valid index value doesn't seem to faze the compiler one bit.

Raw Four-Letter Codes

When AppleScript compiles a script, it uses the dictionary to translate your English-like terminology into Apple events. When AppleScript decompiles a compiled script, it uses the dictionary to translate Apple events to English-like terminology.

It is possible to do AppleScript's job for it and type a raw Apple event directly into a script. There is then no translation to be performed, and no dictionary is needed. Apple events, as we observed in Chapter 3, are constructed of four-letter codes. The notation is a keyword stating what "part of speech" this four-letter code is (such as constant, property, class or event), followed by a space, followed by the four letters (or, in the case of an event, eight letters). The entire thing is wrapped in guillemets, also called chevrons («»). On the U.S. keyboard layout, these are typed using Option-\ and Shift-Option-\ (backslash).

Using raw Apple events, we can target an application using its own terminology but without a tell block and without AppleScript's making any use of the application's dictionary. For example:

get name of «class cdis» 1 of application "Finder" -- "feathers"

The term name is defined by AppleScript, but the term disk is not. Yet we can use the term