Section 10.6. Scope of Undeclared Variables


10.6. Scope of Undeclared Variables

In AppleScript, you do not have to declare variables. When you use a name that, by the preceding rules of scope, is not an existing variable, AppleScript does not complain; rather, it creates the variable for you. How it does this depends upon the location of the code that uses the nonexistent variable name:


Code at the top level

The variable is created as a global. There is no explicit global declaration, so there is no downward effect, but other scopes can see this variable through a global declaration. I call this an implicit global.


Code not at the top level

The variable is created as a local. I call this an implicit local .

Let's illustrate an implicit global first:

 set x to 5 on getX( )     global x     display dialog x end getX getX( ) -- 5

The first line never said explicitly that x should be a global. But it clearly is one, since when getX comes along and asks to see a global called x, the x created in the first line is what it sees. (Incidentally, you can move the "set x to 5" line to after the getX handler definition and the script will still work; the important thing is that the global x be defined by the time getX runs, not necessarily before getX itself is defined.)

Incidentally, a variable created implicitly in a script's top-level explicit run handler is an implicit global as well, just as if you'd declared it at the absolute top level:

 on run     set howdy to "Howdy"     sayHowdy( ) -- Howdy end run on sayHowdy( )     global howdy     display dialog howdy end sayHowdy

That's a very odd rule, as in no other respect (I believe) is an explicit run handler treated like the absolute top level; usually, it's treated like a handler, in which case the implicit variable would be local. This shows the extremes the language goes to in order to cope with undeclared variables.

Now for an implicit local:

 set x to 5 on getX( )     set x to 10     display dialog x end getX getX( ) -- 10 display dialog x -- 5

Clearly we are now talking about two different variables called x. We have already established that the top-level x is global; but getX is evidently not seeing it. It is setting to 10, and displaying, some other x; its actions are having no effect on the top-level x, as the last line proves. So getX's x must be local to getX. To prove that it is truly local and not some sort of magic downward global within getX, we need another test:

 script s     set x to 10     on myHandler( )         display dialog x     end myHandler     myHandler( ) end script run s -- error: The variable x is not defined

But if we reverse the structurea script object in a handler, instead of a handler in a script objectthen it works:

 on getX( )     set x to 10     script s         display dialog x     end script     run s end getX getX( ) -- 10

That isn't because x is not local; it's because of the special exceptional rule that a script object in a handler can see the handler's locals.




AppleScript. The Definitive Guide
AppleScript: The Definitive Guide, 2nd Edition
ISBN: 0596102119
EAN: 2147483647
Year: 2006
Pages: 267
Authors: Matt Neuburg

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net