6.1. Scope BlocksRecall (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:
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".
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. |