AppleScript_ The Definitive Guide - Matt Neuburg [95]
on myHandler( )
set x to 5
end
Is x a local or a global here? You don't know! It depends upon the context. If x has previously been declared global at a higher level, this x is global (by the downward effect of that declaration). If not, this x is local. But it is intolerable that you should have to search elsewhere to learn the scope of x within myHandler!
A particularly tricky problem is presented by script objects loaded from a compiled script file on disk (see Chapter 8). For example:
set f to (path to desktop as string) & "lib.scpt"
run (load script alias f)
x -- "howdy"
Hokey smokes! How is that possible? Where did this variable x come from? It came from the script in the file lib.scpt, which simply says this:
set x to "howdy"
The x in lib.scpt is an implicit global, and when you load and run that script, the global infects your own script's namespace. This is extremely cool or extremely scary, depending on your point of view. It seems cool to be able to make a variable (which can equally be a script object or handler) magically appear, name and all, in your script. My own view, however, is that globals, implicit or explicit , are for this very reason to be avoided in scripts that will be loaded into other scripts. After all, if you didn't know that lib.scpt was going to do this, and your script had its own top-level x, then loading and running lib.scpt would make your script malfunction mysteriously.
The ideal way to manage scope, in my view, would be to declare everything. If you need a variable to be visible in this scope and deeper scopes, then declare a property. (In a handler, merely declaring a local will do.) Otherwise, declare a local. Use global declarations sparingly, only for special occasions when separate regions of scope need shared access to a value. If you follow these rules, then any undeclared variable must be a free variable (see the next section). Thus you always know what everything is. Unfortunately, as I've said, AppleScript doesn't help, so you can't easily and reliably follow these rules, even if you want to.
A local or global declaration, by the way, does not have to appear right at the top level of a scope block; it can be embedded in a control structure. However, it isn't an executable statement; it is seen and enforced by the compiler, not the runtime engine. In this example, 1 is not 2, so the local x declaration is never "executed," but the example shows that x is local anyway:
if 1 is 2 then
local x
end if
set x to 7
on myHandler( )
global x
display dialog x
end myHandler
myHandler( ) -- error: The variable x is not defined
That example is silly, but the ability to declare a variable within a control structure is not, because it encourages and helps you to (you guessed it) declare your variables. You could be deep in the middle of typing a complicated control structure when you suddenly introduce a new variable, and you realize that you want to declare it. You don't have to hunt back through your code looking for a place to declare the variable at the top level; you can declare it where you are and get on with your work.
Free Variables
A variable defined outside a handler or script object, but globally visible within it, and not overshadowed by a declaration of the same name, is called a free variable with respect to that handler or script object. A free variable in AppleScript is identified with a top-level entity or global through the downward effect of its declaration. For example:
global x, y, z
script myScript
property x : 1
local y
yy
z
end script
Within myScript, x is explicitly defined as a property and y is explicitly defined as a local, so neither is a free variable. The variable yy isn't explicitly defined within myScript, but it isn't defined outside it either, so it is an implicit local and not a free variable. But the variable z is globally visible within myScript (from the global declaration at the start of the code), and the name is not redeclared within myScript, so z within myScript is a free variable,