Nonsensical Apple Events

As we saw in a previous section ("Compile-time Error"), AppleScript will sometimes blow the whistle at compile time to indicate that you are using a term as the wrong "part of speech." This is extremely helpful. For example, you can't use a verb as a noun:

tell application "Finder"
    get name of eject -- compile-time error: Expected expression but found command name
end tell

And you can't assign to a class:

tell application "Finder"
    set container to "howdy"
    -- compile-time error: Can't set «class ctnr» to "howdy". Access not allowed
end tell

You have to supply valid parameter names:

tell application "Finder"
    duplicate x by y -- compile-time error: Expected end of line but found "by"
end tell

The duplicate command doesn't have a by parameter, and the compiler knows this.

You can't make an element specifier out of something that isn't a class name:

tell application "Finder"
    get name 1 -- compile-time error: Expected end of line but found number
end tell

The compiler also displays some intelligence about singular and plural forms of a class name. The plural form of a class name is taken to be a synonym for the every element specifier; otherwise, if you use a plural where a singular is expected or vice versa, the compiler will usually change it for you, silently:

tell application "Finder"
    folder -- folder (the class name)
    folders -- {...}, a list of references to every folder
    folders 1 -- compiles as folder 1
    folder 1 thru 2 -- compiles as folders 1 thru 2
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.