[ Team LiB ] |
19.1 Resolution of TerminologyExample 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 resolutiontell 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 DictionaryAs 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 TermsPresume 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 dictionaryOnly 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 termEvery 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:
Let's trace the resolution of the terms in Example 19-1, according to these rules:
(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 codesApple 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.
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 ] |