AppleScript_ The Definitive Guide - Matt Neuburg [170]
Bear in mind that there may be more at stake than terminology clash. There is also the problem of who the target is. Recall this earlier example:
set home to "Ojai"
tell application "Finder"
get home
-- folder "mattneub" of folder "Users" of startup disk of application "Finder"
end tell
The programmer wanted to refer from inside the tell block to the home in the first line. The problem is that there is a terminology clash and the second home is being directed to the Finder instead of the script. It isn't enough retarget the second home:
set home to "Ojai"
tell application "Finder"
get my home -- error: Can't make home directory into type reference
end tell
That's because there's still a terminology clash. The correct solution is to resolve the terminology clash:
set home to "Ojai"
tell application "Finder"
get |home| -- "Ojai"
end tell
This example from Chapter 11, on the other hand, is not a terminology clash:
on reverseString(s)
set text item delimiters to ""
return (reverse of characters of s) as string
end reverseString
tell application "Finder"
set name of folder 1 to reverseString(get name of folder 1)
-- error: Finder got an error: Can't continue reverseString
end tell
The color of the term reverseString in the tell block shows that, to the compiler, this is the same reverseString defined as a handler earlier. But that doesn't matter; the handler call is still going to be sent as a message to the Finder, not to the script. Adding my solves the problem. (See "Handler Calls, Commands, and Script Objects" in Chapter 8, as well as "Terms in Scope" and "Me" in Chapter 11. If your choice of names is sufficiently perverse, you may have to use both my and pipes, as in the reveal example in Chapter 11.)
Clash Between Dictionaries
If a clash is caused by the programmer, the programmer can choose different terms and avoid the clash. But what happens when the same term is defined in two different dictionaries, which are not in the programmer's power?
Clashes between the dictionaries of scriptable applications are not problematic, as you can target only one scriptable application at a time. For instance, both Entourage and the Finder define the term folder, but unless you deliberately pervert the terminology-resolution mechanism with a terms block, no conflict will ever arise.
A term defined in both AppleScript's and an application's dictionary is not necessarily problematic either. In fact, it's expected, provided they are the very same term—the same English-like term and the same underlying four-letter code should be used (and, I should probably add, both dictionaries should use the term as the same part of speech). For example, AppleScript defines the term name ('pnam') as a property of a script object; the Finder defines it as a property of an item. As they both use the same English-like term and the same four-letter code, and they both use it as a property, this is not a conflict. Similarly, both AppleScript and the Finder implement the count command.
Nevertheless, a dictionary can be badly written. The authors of a dictionary are supposed to do their homework, making sure they don't use any terminology that might conflict with AppleScript itself. Sometimes, they don't do their homework (see "Clashes with AppleScript," later in this chapter). Even more insidious is what happens when a scripting addition's dictionary gets into the act. After all, even if an application's dictionary generates a terminology clash, at least the problem arises only if you're targeting