AppleScript_ The Definitive Guide - Matt Neuburg [169]
local year
set year to 2005 -- fine
The term year is the wrong color, but the script runs fine. We may conclude that an explicitly declared variable whose name is that of a defined property is not problematic. The reason, apparently, is that a variable name and a property name are very much alike, and can be used in similar ways. If a name is invented by the programmer, it is one color; if it is already defined as a property name, it's another color (and behind the scenes its four-letter code is used). But syntactically they are largely interchangeable, as long as AppleScript doesn't get confused about what role the name is playing in its current context. That, presumably, is why the declaration is necessary: it says to AppleScript, "I know this is an existing property name, but I'm using it as the name of a variable here." (Recall how the name of a record item can be an existing property name or a "user property" name—see "Record Properties" in Chapter 13.) As a result, and rather surprisingly, this code works perfectly:
local bounds
tell application "Finder"
set bounds to (get bounds of item 1)
end tell
bounds -- {-33, -33, 31, 31}
Within the tell block, the term bounds is being used in two different ways, yet AppleScript knows which is which. The reason, ironically, is that bounds is already defined by AppleScript as the name of a property. Thus all four occurrences of bounds are the same color when pretty-printed: they are all property names. Just as important, they have the same four-letter code: they are all the same property name. The variable declaration at the start puts bounds in scope as a variable name; inside the tell block, it can also be resolved as the name of a Finder property. In the third line, AppleScript identifies the second bounds (the one after get) with the Finder's bounds, but it identifies the first bounds (the one after set) with the variable bounds defined in the first line. The difference is that the first bounds (the one after set) has no of (or its, which would amount to the same thing); thus it is not explicitly said to be a property of the Finder, and is identified with the variable bounds instead.
To understand better the circumstances under which this sort of thing works, contrast some situations in which it doesn't work. It doesn't work if there is no explicit declaration of the variable bounds:
tell application "Finder"
set bounds to (get bounds of item 1)
-- error: Finder got an error: Can't set bounds to {-33, -33, 31, 31}
end tell
In that example, the first bounds is identified with the Finder's bounds property, because there's nothing else for it to be identified with.
And here, the variable name home, though declared explicitly, cannot be identified with the home in the tell block, because the former is a name created by the user; it is not an existing property name whose four-letter code matches that of the Finder's home:
local home
tell application "Finder"
set home to (get bounds of item 1)
-- error: Finder got an error: Can't set home to {-33, -33, 31, 31}
end tell
Resolving Terminology Clash
If you are aware of a terminology clash caused by your choice of name, your best option is to avoid the conflict altogether: don't use problematic names in the first place! If you insist upon using a problematic name, however, you can usually resolve the conflict (as explained earlier in the section "Me" in Chapter 11) by using pipes (vertical bars) to suppress AppleScript's interpretation of something as a dictionary term. Many of the examples that wouldn't compile or run correctly earlier in this section work perfectly if you add pipes:
local |count|
set |count| to 0
set |year| to 2005
set sel to {length:2, |offset|:4}
local |desktop|
tell application "Finder"
set |container| to 7
end tell
tell application "Finder"
script |eject|
end script
end tell
on |beep|(what)
display dialog what
end |beep|
beep 1 -- beeps
|beep|("howdy") --howdy
If a scripting addition was not present when a script was compiled and is present