DekGenius.com
[ Team LiB ] Previous Section Next Section

19.1 Resolution of Terminology

Example 19-1 consists of a little code exhibiting some common patterns of terminology usage; we will use it as an example to help us form a mental picture of AppleScript's compilation process.

Example 19-1. Simple terminology resolution
tell application "Finder"
        set r to display dialog (get name of folder 1)
end tell

Compilation of code like Example 19-1 proceeds in two distinct stages. First the tell block causes AppleScript to locate a particular application and load its dictionary. Then the terms inside the tell block are resolved. Let's take these stages one at a time.

19.1.1 Loading the Dictionary

As AppleScript's compiler encounters a tell block targeting an application, it immediately attempts to locate this application, so that it can load its dictionary. If the compiler can't find the application, it will ask the user where it is; if the user cancels out of this process, refusing to choose an application, AppleScript will not compile the script.

(If the current instance of the AppleScript scripting component has already loaded a particular application's dictionary, it doesn't need to do so again, because it now has a copy of the dictionary cached in memory. This is one of the reasons why a script typically takes longer to compile the first time.)

AppleScript will proceed happily at this point, provided it can find the application, or the user chooses an application for it—any application. The compiler has not yet come to the point of trying to resolve any actual terminology, so it doesn't matter at this stage whether there is any terminology to resolve, or even whether the application has a dictionary. All that matters is that the application referred to in code should be identified with some actual application. See Section 4.4.3.

Example 19-1 consists of a single tell block, but there are other situations that will cause a dictionary to be loaded. The tell block might contain another tell block that names another application; in that case, that application's dictionary will also be loaded. The same thing happens if a terms block is encountered (Section 12.4). The question of whether the running script will eventually target any of these applications is completely irrelevant; the dictionaries will be loaded anyhow.

19.1.2 Translating the Terms

Presume that the compiler has reached the interior of the innermost tell block or terms block that caused a dictionary to be loaded. The compiler now proceeds to resolve the actual terms of the block.

19.1.2.1 The innermost application dictionary

Only one application dictionary is involved in the resolution of terminology in a given context. This is the dictionary corresponding to the innermost surrounding terms block or tell block. Let's call this the innermost application dictionary.

So, for example, in the following code, it is the Finder's dictionary that is the innermost application dictionary, and it will be used to resolve the term folder (and this resolution will succeed):

using terms from application "Mailsmith"
        tell application "Finder"
                get name of folder 1
        end tell
end using terms from

In the following code, it is Mailsmith's dictionary that is the innermost application dictionary, and it will be used to resolve the term folder (and this resolution will fail, so that the code will not compile):

tell application "Finder"
        using terms from application "Mailsmith"
                get name of folder 1
        end using terms from
end tell
19.1.2.2 Hunting for each term

Every term used in a given context must be found in a dictionary in order to be resolved. But the innermost application dictionary is not the only place where AppleScript may have to look, because some of the terms may be defined elsewhere. The hunt for terminology thus involves several steps. Here's how it goes:

  1. At every step of the hunt, if a term is found as a property in a dictionary, and if it isn't linked to some object by of (or one of its synonyms), it is also sought as a variable in the current scope of the script itself; if it's found as a variable in the script, it is resolved as that variable.[1]

    [1] This rule is my attempt to codify a kind of short-circuiting that AppleScript performs in order to allow variables to be accessible even within a tell block (see Section 10.2.5). Even after much experimentation I may still not quite have succeeded in formulating the rule perfectly.

  2. The term is sought in the innermost application dictionary.

  3. The term is sought in AppleScript's own dictionary (described later in this chapter under Section 19.4 and in Appendix A).

  4. The term is sought in the dictionaries of any scripting additions that are present.

  5. The term is sought in the script itself.

Let's trace the resolution of the terms in Example 19-1, according to these rules:

  • The terms set and get are not defined in the dictionary of the Finder, so they are sought and found in AppleScript's own dictionary (rule 3).

  • The term r isn't found anywhere, so it's sought in the script; that works fine in this syntactic context, because r is being used in a place where it can be the name of an implicitly defined local variable (rule 5).

  • The term display dialog isn't found in the Finder's dictionary or in AppleScript's own dictionary, but it's defined in a scripting addition's dictionary (rule 4).

  • The term folder is defined in the Finder's dictionary (rule 2).

  • Definitions for the term name appear both in the Finder's dictionary and in AppleScript's own dictionary. The former is used in the present case (rule 2); the latter explains how name is resolved in the last line of the example at the end of Section 11.1.1.

(Example 19-1 did not illustrate the use of rule 1; this rule is rather tricky, and we'll explore it more fully in a moment.)

19.1.2.3 Substituting four-letter codes

Apple events are made up chiefly of four-letter codes. (See Example 4-1, where the four-letter codes have values like 'core', 'move', 'insh', 'insl', 'kobj', 'obj ', 'kpos', 'form', 'want', and 'seld'.) Having located a term in a dictionary, the compiler uses the term's dictionary definition to translate that term into a four-letter code so that it can build an Apple event.

These four-letter codes are actually integers. An integer is four bytes, while a character from the ASCII range is one byte; so an integer can express four "packed" characters. The expression of this integer as a four-letter string is simply a convenience for the human reader. The use of single quotes to delimit a four-letter code is a standard convention.


Think of a term as either a noun or a verb; a command is a verb, and everything else is a noun. These are fundamentally different grammatical entities in an Apple event just as they are in a human utterance, and the dictionary makes clear which is which. So, for example, the Finder's dictionary stipulates that eject is a verb, while folder is a noun. (Actually it says that eject is an event, while folder is a class. We'll talk more about these technical notions later in the chapter, under Section 19.3.)

The dictionary defines each verb as a pair of four-letter codes, and each noun as a single four-letter code. For example, the Finder's dictionary defines eject as 'fndr/ejct', and it defines folder as 'cfol'.

Thus, having found each term of a line of code in some dictionary, the compiler is able to use these four-letter codes, along with the line's grammar, to construct the Apple event that will eventually be sent to the application.

    [ Team LiB ] Previous Section Next Section