AppleScript_ The Definitive Guide - Matt Neuburg [181]
There's no formal marker in an 'aete'-format dictionary to distinguish a record from a class. Script Editor's dictionary display thus does nothing to let you know that a class might really be a record. Script Debugger, on the other hand, does some detective work. If a class has no elements and is not an element of any class, Script Debugger calls it a record. This results in some false positives (the Finder's Finder preferences property, for example, is not a record, though Script Debugger calls it one), but it's still a helpful heuristic. In an sdef-based dictionary, the distinction can be made formally, so we can expect dictionary displays to be positively useful in this regard as applications begin to adopt the sdef format.
Events
Events are the verbs of the AppleScript language. An event is an Apple event (Chapter 3). An Apple event is specified using two four-letter codes. So, for example, the Finder's reveal command is the event 'misc\mvis'.
(In reality the two four-letter codes together are simply a 64-bit integer. The exact convention used to present them to a human reader is unimportant. I like to separate them with a backslash. Others use a forward slash, or put each half in single quotes, or whatever.)
An Apple event can take parameters . The default parameter is the "direct object "; its four-letter code is '----', which has no English equivalent. Others parameters have names; the name is a four-letter code, like a property. (See "Event Handlers" in Chapter 9 and "Target" in Chapter 11.)
The dictionary entry for an event lists the following information:
The event itself
The event's four-letter codes and its English name are provided.
The direct object
The direct object is marked as existing or not existing. If it exists, its value type is given, and it is marked as either optional or required .
Other parameters
Each parameter's four-letter code and English name are provided. The value type is specified. The parameter is marked as either optional or required.
Returned value
The event's returned value (result ) is marked as existing or not existing. If it exists, its value type is given, and it is marked as either optional or required.
The dictionary display expresses essentially the same information: it tells you a command's name, the names and value types of the parameters (and whether they are optional), and the value type of the result, if any. Figure 20-6 shows the Script Editor's display of iTunes's add command. The direct object is said to be a list of alias; the to parameter is said to be a location reference, and optional (that's the meaning of the square brackets); and the result is said to be a track. Script Debugger's display (Figure 20-6) includes a template for actually using the command and a tabular display of its parameter information; if you press the Tell button in the toolbar, the command template is pasted into your script.
In an sdef-based dictionary, a distinction can be made formally between commands (Apple events that your script sends) and events (Apple events sent by an application to your script, as discussed in "Event Handlers" in Chapter 9). In the future, therefore, we can expect dictionary displays to reflect this distinction.
Figure 20-6. Script Debugger's display of a command
The AppleScript compiler enforces the rule that the only parameters following a command should be the direct object and the labeled parameters defined by that particular command. It knows nothing about required and optional parameters, and it does not enforce the value types expected for each parameter.
Suites
At the top level of a dictionary, events and classes are grouped into suites. You can see this in Figure 20-2, where the first column of the browser at the top of the Script Editor dictionary display consists of suites: the Standard suite , the Finder Basics suite, the Finder Items suite, and so forth.
A suite is in large part just a device for organizing the top level of a dictionary. Whether this is a good organizational device is a matter of