AppleScript_ The Definitive Guide - Matt Neuburg [166]
Loading a dictionary takes time, and may even require launching the application in question, which takes even more time. Once the current instance of the AppleScript scripting component has already loaded a particular application's dictionary, however, it doesn't need to do so again, because it now has a copy of the dictionary cached in memory. These are some of the reasons why a script typically takes longer to compile the first time.
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.
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 where an application is explicitly specified. Let's call this the innermost application dictionary .
The interaction between nested terms blocks and tell blocks in determining the target and the innermost application dictionary was described in Chapter 11 and Chapter 19. Recall that iTunes is not targeted in this code:
tell application "iTunes"
tell application "Finder"
count folders
end tell
end tell
So iTunes's dictionary will be loaded at compile time (and this will necessitate launching iTunes if it isn't running already) but it will not be consulted because it isn't targeted. iTunes knows nothing of folders, but this doesn't matter. On the other hand, it does matter in a case like this:
tell application "Finder"
using terms from application "iTunes"
count folders -- error: The variable folders is not defined
end using terms from
end tell
The terms block deliberately perverts AppleScript's use of dictionaries. AppleScript, instructed explicitly to look in iTunes's dictionary, never learns that folder is defined in the Finder's dictionary, nor does it find folder in iTunes's dictionary. Thus it thinks folders is the name of a variable; that variable is undefined at runtime, causing an error.
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:
The commands get and set (and sometimes copy) are specially short-circuited and are not sought in any dictionary.
The term is sought in the innermost application dictionary. (But see "No Terminology Clash," later in this chapter.)
The term is sought in AppleScript's own dictionary (described later in this chapter, under "The 'aeut' Resource").
The term is sought in the dictionaries of any scripting additions that are present.
The term is sought in the script itself.
Let's trace the resolution of the terms in Example 20-1, according to these rules:
The term set (and its parameter to) are short-circuited (rule 1).
The term folder is defined in the Finder's dictionary (rule 2).
The term count appears both in the Finder's dictionary and in AppleScript's own dictionary. The former is used in the present case (rule 2).
The term string appears in AppleScript's own dictionary (rule 3).
The term display dialog is defined in a scripting addition's dictionary (rule 4).
The term c isn't found anywhere, so it's sought in the script, and is resolved as the name of an implicitly defined local variable (rule 5).