Section 6.1. Scope Blocks

6.1. Scope Blocks

Recall (from "Blocks" in Chapter 5) that a pretty-printed script displays its structure by means of indentation. Every set of indented lines is introduced by an on line and terminated by a corresponding end line. The whole thing is a block . For example, this is a repeat block:

 repeat 3 times     display dialog "Howdy" end repeat

It turns out that two types of block are very special in AppleScript: a script object definition and a handler definition. They are special in many ways. These are the only blocks that function as what I'll call top-level entities in a script. They are not merely blocks; they are also variable definitions. There are special rules for where they occur in a script. Most obviously, they are the regions of scope in a script; for this reason, I call them the scope blocks.

Scope will be fully discussed in Chapter 10, but the idea is very simple. Some parts of a script are divided off from other parts by a kind of magic wall of impenetrability. Even if the parts can see each other, they cannot necessarily see inside one another. The word scope is the technical term for the visibility of part of a script: the scope of a thing is precisely equivalent to the rules for what parts of a script can see that thing. A script object definition and a handler definition are the only two kinds of block with the ability to put up these walls. They delimitand in essence, arethe regions of scope within a script, the regions that are divided from one another by special rules as to who can see what. No other blocks have this magic power.

So what do they look like, these two special types of block? That's very simple. A script object definition is a block announced by the keyword script:

 script scriptName     -- commands within the script object end script

A handler definition is a block announed by the keyboard on:

 on handlerName( )     -- commands within the handler end handlerName

And what do they actually do? They define, respectively, a script object and a handler. But what's a script object and a handler? That's a bit harder to explain: it's pretty easy to understand what a script object is or what a handler is through examples showing them in action and illustrating the full set of rules for how they work, but it's not so easy to see, out of context, what they're for and how they differ. But here are some quick descriptions, just to satisfy your natural curiosity:

handler

A handler is a subroutine, or what some languages call a function. It's a block of code that has a name, and the code can be executed (called) by saying the name. A handler can also receive parameters, which are values that it should operate on when it is executed. A handler is a convenient and powerful way to distinguish and give a name to some code, often to avoid needless repetition when you're going to execute the same code on different occasions (instead of repeating the whole code, you just repeat the handler callbasically a single word), or just as a way of improving the organization and development of a script.

For example, suppose a handler definition defines a handler called capword which takes any string and capitalizes each word of the string. Then any time you want to capitalize the words of any string in your script, you just call capword. Whatever string you hand to capword is its parameter . If you call capword with "hello there" as the parameter, it returns "Hello There".

script object

A script object is also a named block of code, like a handler, but it's more all-inclusive, more independent, and more persistent. As its name implies, a script object is essentially an entire script within a script.

That definition of a script object wasn't very helpful, but it will have to do for now. Later we'll talk about all that a script object is and all that it can do. It might be useful at present, though, for you to keep in mind the following. In some ways a handler and a script object are rather similar. They are both units or packages of code. And they are both units of code that you can talk to; you can say to a handler, "Execute the code that's within you," and it will turn out that you can say much the same thing to a script object . But there are some important differences in how you talk to them. Asking a handler to execute its code is all you can say to handler; you call the handler and that's it. But you don't call a script object; you send a message to it, and that message can be anything. It's almost as if a script object is itself a little scriptable application and you're talking to it with Apple events. That's not exactly the case, but it's got the right flavor, and will give you something to chew on until we reach the formal presentation in Chapter 8.

What is the cumbersome word "definition" doing in my explanation of an on block and a script block? Strictly speaking, there is a real distinction to be drawn here. A handler or a script object is some code; a handler definition or a script object definition is a block stating what that code is. This distinction will become important later in the book, when it turns out that a script object or a handler is really just a value like any other value (like the number 5 or the string "howdy"), whereas the block is really just a way (and not the only way) of creating and giving a name to that value. Nevertheless, the bare terms "handler" and "script object" (without "definition") are very often used loosely and conveniently to mean the blocks , and I will use them this way too where there is no danger of confusion.