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 tell
 
tell application "Finder"
    tell folder 1
        h( ) -- error: Finder got an error: Folder 1 doesn't understand the h message
    end tell
end tell
 
tell application "Finder"
    using terms from application "iPhoto"
        start slideshow -- Finder got an error: Can't continue start slideshow
    end using terms from
end tell
 
tell application "Finder"
    h( ) -- error: Finder got an error: Can't continue h
end tell

The get and set commands (and also sometimes copy) are treated in a special way: they are not messages in the sense just mentioned, but are instead somehow short-circuited so that they always work. The reason is, I suppose, that otherwise it might be possible for code or a target application to break or interfere with them and then nothing would work at all.

The message-target metaphor is also made somewhat problematic by the existence of scripting additions (see Chapter 21). Scripting additions cannot be targeted, but the commands they implement are available everywhere.