AppleScript_ The Definitive Guide - Matt Neuburg [186]
Properties with Eponymous Classes
A common developer mistake is to give a property the same name and four-letter code as a class. This causes errors in the user's script that can be difficult to track down. Also, it's just confusing.
For example, in Entourage, a message has recipients, and a recipient has an address property which is itself of the address class. To learn, as a string, who the addressee is, you have to ask for an address's address property. This requires a nutty way of talking ("address of address"?); and to make things worse, it doesn't seem to work:
tell application "Microsoft Entourage"
tell folder 1
tell message 1
tell recipient 1
get address of address -- error: Can't get address of address
end tell
end tell
end tell
end tell
The problem is that a property and a class have the same name; this causes the script to resolve the terms incorrectly. To solve the problem, you must help AppleScript to understand that you mean the property, not the class:
tell application "Microsoft Entourage"
tell folder 1
tell message 1
tell recipient 1
get address of its address -- "matt@tidbits.com"
end tell
end tell
end tell
end tell
Even worse is what happens when a property and a class have the same four-letter code but different English-like names. For example, in Panther, here's what happens when you ask the Finder for the class of its desktop property:
tell application "Finder" to get class of desktop -- desktop
But there is no desktop class! The correct answer is desktop-object; the problem is that the four-letter codes for desktop-object and desktop are the same. (The term desktop comes first in the dictionary and hides the term desktop-object during decompilation.) The mistake is fixed in Tiger's version of the Finder dictionary.
Clashes with AppleScript
An application's dictionary should not clash with the AppleScript language itself. When it does, the language is perverted, and scripts that should compile don't, or compile oddly.
We've already seen some examples of trouble caused by poor choice of terminology in an application's dictionary. The use of the term end transaction by FileMaker Pro as the English-like equivalent of the 'misc\endt' Apple event conflicts with AppleScript's own use of end transaction as the closing phrase of a transaction block. BBEdit's use of the term contents as a property of a text-object conflicts with AppleScript's own contents of operator.
Another example is Entourage's recipient class, which has a recipient type property whose four-letter code is 'rtyp'. This conflicts with a fundamental feature of the AppleScript language—it's the same as the as in get...as (see Chapter 14). Thus if you enter this code:
tell application "Microsoft Entourage"
get path to desktop as string
end tell
it compiles and decompiles to yield this (after which, of course, it won't compile at all):
tell application "Microsoft Entourage"
get path to desktop recipient type string
end tell
Wrong Value Types
Dictionaries are notorious for stating incorrectly the value type of a property, a command parameter, or a command return type. Only experimentation will reveal the truth.
For example, Entourage's application class lists the value type of most of its properties as "reference" (meaning 'obj '; see "Value Types," earlier in this chapter). This is true as far as it goes, but it's unnecessarily vague. The class of the in box folder property, for example, is folder; it will never be anything else. So why not say so in the dictionary?
We saw earlier that iTunes misstates the class of the direct object of the convert command. Recall also that GraphicConverter's dictionary says it expects an alias as the in parameter of the save command. That puts the user in a quandary, because you might want save to create a new file, but you can't use an alias where the file doesn't already exist. Experimentation reveals that a string will do: