AppleScript_ The Definitive Guide - Matt Neuburg [168]
set count to 0 -- error: Can't set count of 0 to
It's okay to use a defined property name as the name of a variable, but not if you don't declare it:
set year to 2005 -- error: Can't make year into type reference
If you do declare it, it's fine:
local year
set year to 2005 -- fine
No Error, Surprising Behavior
A terminology clash where the compiler doesn't complain and there is no runtime error is potentially the worst case for the programmer, because the code runs but it doesn't behave as expected. Here's an example:
local container, x
set container to "howdy"
tell application "Finder"
set x to container
end tell
x -- container, not "howdy"
The programmer was trying to set the variable x to the value of the variable container. But in the context of a tell block targeting the Finder, container is the name of a class, so the variable x ends up with that class as its value.
Here's a similar example from "Me" in Chapter 11:
set home to "Ojai"
tell application "Finder"
get home
-- folder "mattneub" of folder "Users" of startup disk of application "Finder"
end tell
If you create a handler name that clashes with the name of a scripting addition command, you can make it impossible to call the scripting addition command. For example, the beep scripting addition command is supposed to take one optional parameter, the number of times to beep. If you define a handler called beep, the beep scripting addition command becomes inaccessible:
on beep (what)
display dialog what
end beep
beep 3 -- 3, not beep beep beep
AppleScript accepts the syntax beep 3 because that's correct syntax for the event as defined in the scripting addition; but at runtime it routes the call to your handler.
Detecting Terminology Clash
Terminology clash that prevents compilation is good; the script won't compile, but at least you were saved from the problem before execution of the script was underway. Terminology clash that doesn't prevent compilation is a tougher nut to crack: either there's going to be a runtime error or, even worse, the script will execute without error but will do the wrong thing. How can this situation be avoided?
An important clue that a terminology clash is brewing is the pretty-printing of the compiled and decompiled script in your script editor application. (The pretty-printing occurs after compilation but before execution, so this is a good reason to compile and run in two separate steps.) AppleScript's preferences can be set so that, when your script is pretty-printed, terms defined in your script have a different color or style from other terms. (To set these preferences, use the Preferences dialog of a script editor application.) If you think a term is being defined in your script, but it doesn't have correct color and style, trouble may lie ahead. For example:
set count to 0
set myVar to 10
On my machine, count and myVar are colored differently. This is a bad sign, and should make me stop and think before executing this script. Why don't they have the same status? Aren't they both variable names defined by my script? Thinking about this, I might realize that count is the name of a command defined by AppleScript, and is a bad choice of name for a variable.
Look back over earlier examples. In the example with home, the local variable home and the home in the tell block targeting the Finder appear in different colors in my script editor application; this should tell me they refer to two different things, which is not my intention, so the script is going to misbehave. Exactly the same thing happens in the example with container. In the example with beep, the term beep is the wrong color everywhere; this should warn me that I may be trying to use a term that's already defined elsewhere, which may have unexpected results.
No Terminology Clash
Sometimes the pretty-printed terminology colors seem to threaten a terminology clash, but there isn't one.