AppleScript_ The Definitive Guide - Matt Neuburg [180]
The Script Editor helps you with a "containment" view of a dictionary's classes (Figure 20-2; to see the containment hierarchy, you would press the second segment of the View button in the toolbar). Script Debugger goes further, drawing a graph of the tree rooted at any class that has elements. Even more important, Script Debugger has an Explorer view that probes a running application's object model in real time, showing all elements and properties for every actual object in the hierarchy at that moment, telling you their values and showing you how to refer to them (see Figure 2-4).
The AppleScript compiler does not enforce the distinction between a property and an element, and does not enforce encapsulation—for example, it doesn't look in the dictionary to see whether the property you are ascribing to an object really is a property of that object. See "Nonsensical Apple Events," earlier in this chapter.
Records
When the result of a command sent to a scriptable application is an object of a class defined by that application, it is usually a reference to an object in that application's world (Chapter 12). For example, when you ask BBEdit to get document 1, what comes back is a reference to document 1—you aren't handed the entire literal document. If you want to know more about document 1, you can explore its properties, and when you do, an Apple event is sent to BBEdit. That's because this object lives in BBEdit's world; all you've got is a reference:
tell application "BBEdit"
set d to document 1 -- result is a reference
get name of d -- sends Apple event to BBEdit
end tell
But sometimes what happens is quite different. You receive from the application what appears to be an object. It has properties. It seems to be an object of a class defined by the target application. But examining its properties doesn't cause any Apple event to be sent. What you have isn't a reference: it's the entire object itself:
tell application "BBEdit"
set d to find tag "style" start_offset 0
class of d -- tag result
start_offset of tag of d -- 225; no Apple event is sent
end_offset of tag of d -- 259; no Apple event is sent
end tell
What you've got is actually a record (Chapter 13) disguised as a class. You can think of it as a pseudo-class. In the dictionary, it's listed as a class. You have no certain way of knowing, from the dictionary display, that this command yields a record rather than a reference to an object. And if you ask it what class it is, this thing says tag result, not record. But that's just trickery. It is a record—a record with an item named class! Thus when you ask it for its class, you're given the value of that item, which is tag result.
The example illustrates why this device is useful. BBEdit wants to hand you a package of information consisting of a whole bunch of values at once. These values have names so that you can examine the ones you're interested in. A record is a perfect vehicle for conveying this, because that's precisely what a record is—a package of name-value pairs. At the same time, this record needs to be described in the dictionary, because if it weren't, it would be useless to you. A record has no introspection! You can't ask a record: "So, what properties have you got?" You have to know in advance. The description of the record in the dictionary tells you what properties the record has and what they signify. To provide you with this description, the dictionary simply treats the record as a class; the record properties are treated as class properties (and the "class" has no elements).
Because the names of the properties of this record are defined in the target application's dictionary, you may not be able to extract them outside a tell block targeting that application. For example, this doesn't work:
tell application "BBEdit"
set d to find tag "style" start_offset 0
end tell
start_offset of tag of d -- error: Can't