AppleScript_ The Definitive Guide - Matt Neuburg [100]
set f to (path to desktop as string) & "myScript.scpt"
set s to load script alias f
set greeting to "Bonjour"
property farewell : "Au revoir"
run s -- Bonjour, thenByebye
The point is that there must be something named greeting at a higher level to which the script object's free variable greeting can look to obtain a definition, or there will be a runtime error saying that greeting is not defined.
The same thing happens if there is a global declaration in the stored script object. Let's say we store our script object like this:
set f to (path to desktop as string) & "myScript.scpt"
script s
global greeting
display dialog greeting
end script
store script s in file f replacing yes
When we load the stored script into a new context, there's no closure for greeting. But greeting is declared global, so we can supply a value:
set f to (path to desktop as string) & "myScript.scpt"
set greeting to "Howdy"
run (load script alias f) -- Howdy
Chapter 11. Objects
The purpose of AppleScript is to communicate with scriptable applications. Within the language, these applications present themselves as objects—things to which you send messages, asking for access to their private world of attributes. This metaphor has been extended in AppleScript in a general way (though not, perhaps, with perfect rigor or consistency) to pervade the whole language, so that every value within it is, to a greater or lesser degree, somewhat like a scriptable application. Thus, whether or not AppleScript is an object -oriented language, or even an object-based language, it has a general flavor of involving objects: at every moment in your code, you are talking to something, and most of the things to which you talk have attributes. This chapter is about aspects of the language that involve talking to objects and referring to their attributes.
Messages
The fundamental activity in AppleScript is that of sending messages. Every line of code contains at least one imperative verb. There are actually two kinds of imperative verb: a handler call, which matches a handler definition in your script, and a command , which matches an event defined in a dictionary. The imperative verb is always directed to some specific target , which is supposed to obey it. The medium of communication between the imperative verb in your code and the target that you're talking to is a message .
An object is anything that can be targeted by a message. The most important targets in AppleScript are scriptable applications, but a script object can be a target too, and indeed, in some sense, every value can be a target. So, to that extent, everything in AppleScript is a kind of object. (See also "Object-likeness" in Chapter 4.) For example, count is a command. In a context where the target is the Finder, saying count causes a message to be sent to the Finder. In a context where the target is a script object, saying count causes a message to be sent to that script object. In a context where the target is a string, saying count causes a message to be sent to that string.
AppleScript tries to give the impression that all messages have the same status. Consider, for instance, what happens when an object can't obey a message. If the target is anything other than an application, we are told that the object "doesn't understand the so-and-so message." If the target is an application, we are told: "Can't continue so-and-so." The wording of the error is the same, though, no matter whether the imperative verb that generated the message is a handler call or a command.
tell 1
count -- error: 1 doesn't understand the count message
end tell
script s
end script
tell s
h( ) -- error: «script s» doesn't understand the h message
end tell
tell application "Finder"
tell folder 1
using terms from application "iPhoto"
start slideshow
-- error: Finder got an error: Folder 1 doesn't understand the start
slideshow message
end using terms from
end tell
end