AppleScript_ The Definitive Guide - Matt Neuburg [65]
set myVar to 5
set mybar to myvar + 1
Here's the same code after compilation:
set myVar to 5
set mybar to myVar + 1
In that code I have accidentally created and set the value of an unwanted variable mybar in the last line. I meant to say myvar, but I mistyped it. This won't cause AppleScript to generate any error, and the script will misbehave. The chances that I will spot my mistake are increased by my use of the case trick.
Warning
But this trick is not easy to implement, and it's unreliable because you still might not spot the mistake. The truth is that incorrect variable names are a notorious cause of bugs in scripts, and can be extremely difficult to track down. The real problem is that AppleScript doesn't require you to declare your variables (and unlike Perl with its strict mode, it doesn't let you require it to require you). In my view, this is one of many instances where a feature probably intended to make the language easier actually makes it harder.
Memory of Variable Names
Once a script has been compiled for the first time, its variable names are remembered as they appear at that moment. (Recall that AppleScript has a memory. See "Maintenance of State" in Chapter 3.) Suppose you compile this script:
set avariable to 7
You then change the script to give the variable name inner capitalization:
set aVariable to 7
When you compile, AppleScript removes the inner capitalization!
set avariable to 7
The reason is that when AppleScript first saw the variable name avariable—the first occurrence during the first compilation of the script—it had no capitalization, and that's how the name is remembered from then on.
In Script Editor, this rule washes over to other scripts that you edit during the same session! To see this, start up Script Editor and compile this script:
set myvar to 7
Now open a new, different window and compile this script:
set myVar to 7
Your variable names are changed in this second script! It ends up looking like this:
set myvar to 7
This is because Script Editor uses just one AppleScript scripting component instance per session (that is, until you quit Script Editor). This instance is shared by all the scripts you compile during that session, so the variable names in one script affect the variable names in another. Two different applications don't share the same AppleScript scripting component instance, though, so your variable names in Script Editor do not affect your variable names in Script Debugger at the same moment. Furthermore, Script Debugger uses a different AppleScript scripting component for each script window, so variable names in different scripts don't affect one another.
Variable Names and Vertical Bars
You can force an illegal variable name to be legal by surrounding it with vertical bars, also known as "pipes" (|). So, for example:
set |1| to 2
if |1| is 2 then
display dialog "The laws of logic are suspended."
end if
The laws of logic aren't really suspended; 1 and 2 have not become the same number. A variable named "1" has been assigned the value 2, that's all. This device is good also for variable names in languages other than English:
set |monZéro| to 0
or for spaces in a variable name:
set |my big long variable name with spaces| to 7
A variable name surrounded by pipes is case-sensitive. This script will compile, but it won't run:
set |MyVar| to 5
set |MyVar| to |Myvar| + 1 -- error
The reason is that |Myvar| is not the same variable as |MyVar| and has never been given a value, so its value can't be fetched. AppleScript will not touch the case of names in pipes after compilation.
A variable name surrounded by pipes may include a backslash as an "escape" character. The legal escape expressions in this context are \n, \r, \t, \|, and \\.
The real effect of pipes is to tell AppleScript to suspend its compile-time parsing rules and turn what's inside the pipes into a token. The main reason this is genuinely