AppleScript_ The Definitive Guide - Matt Neuburg [66]
set |is| to "ought"
You couldn't do that without the pipes, because is is a reserved word, a part of the AppleScript language.
Now, you might say: "So what? I'll never need to worry about that; I just won't use any names that conflict with terms that are in use." But it's not so easy. Lots of terms are in use (by AppleScript, by scripting additions, and by the application you're targeting), you can't possibly know what they are, and conflicts are all too easy to stumble into. The use of pipes is a common way to stumble back out. (See "Extensibility and Its Perils" in Chapter 4, and "Terminology Clash" in Chapter 20.)
Chapter 8. Script Objects
A script object is a script within a script. In fact, a script really is a script object, though it also has a special status as the top-level script object. Script objects have certain remarkable features. They have variables of a special kind—I call these top-level entities—that belong to the script object, but can be retrieved and assigned to from elsewhere. They have a run handler, implicit or explicit; the code in this run handler can be executed. They are persistent over repeated executions of a script. They can be saved to disk as files, and a compiled script file can be turned back into a script object. And script objects can even implement a relationship of inheritance with polymorphism. You can think of a script object as a powerful, semi-autonomous package for some code and variables that go together. This chapter presents script objects and their distinctive features.
Script Object Definition
A script object is defined using a block with the keyword script:
script scriptName
-- commands within the script object
end script
A script object definition may appear anywhere. If defined at the top level of a script object (or script), it is a top-level entity ("Top-Level Entities," later in this chapter). It functions as a scope block . (The rules of scope appear in Chapter 10.) Read Chapter 6 for an overview of how script object definitions fit into a script's overall structure.
A script object definition is just that—a definition. Merely encountering a script object definition in the course of execution does not cause of any of its commands to be executed. Rather, a script object definition is a form of variable initialization. So, for example:
script s
display dialog "howdy"
end script
That code does not cause a dialog to display. It defines a script object with an implicit run handler; that run handler contains code that puts up a dialog, but the mere definition does not cause the run handler to run. The script object itself is the value of a variable. Here, that variable is s; when this code is encountered, the variable s is defined and initialized, and its initial value is the script object described by this block of code.
Run Handler
Every script object has exactly one run handler. This may be explicit (all the code marked off by an on run block) or implicit (all the code at the top level of the script object). See "Code and the Run Handler" in Chapter 6.
To execute the code in a script object's run handler, you send the run message to it. You can do this by making the script object the direct object of the run command, or by saying run within a tell block targeting the script object. So, for example:
script s
display dialog "howdy"
end script
run s -- Howdy
Or:
script s
display dialog "howdy"
end script
tell s
run -- Howdy
end tell
A one-line tell block can be reduced to a single line of code with no block:
script s
display dialog "howdy"
end script
tell s to run -- Howdy
(On the result of a run handler, see "Returned Value" in Chapter 9. On passing parameters to a run handler, see "The Run Handler" in Chapter 9.)
Warning
If a script object has no explicit run handler and has no executable statements in its implicit run handler, telling it to run can have unpredictable consequences (this fact is almost certainly a bug).