AppleScript_ The Definitive Guide - Matt Neuburg [173]
There are not many situations where this sort of thing is necessary, but it can be a useful strategy to know about. There are times when it can be a way of resolving a terminology conflict . Recall that earlier I mentioned a longstanding conflict between BBEdit and the offset scripting addition command. A similar problem exists when trying to use the path to scripting addition command while targeting System Events (I owe this example to John Gruber):
path to application support from user domain
-- alias "feathers:Users:mattneub:Library:Application Support:"
tell application "System Events"
path to application support from user domain
-- alias "feathers:Library:Application Support:"
end tell
The very same scripting addition command gives a different answer depending on whether the context targets System Events or not. The System Events answer is wrong, and is caused by the fact that System Events defines a user domain property, which conflicts with the user domain enumerator in StandardAdditions. (It's the same four-letter code with the same English-like terminology, but used as a different "part of speech.") You can work around the problem by using raw four-letter codes:
tell application "System Events"
path to application support from «constant fldmfldu»
-- alias "feathers:Users:mattneub:Library:Application Support:"
end tell
You may find use of four-letter codes not very satisfactory as a solution to terminology conflict, because the original problem recurs the next time the script is compiled. Take the previous example. When we run the script, the four-letter code decompiles to user domain. That's fine as long as the script doesn't need recompilation; but if the script is edited, then the next time we compile, this term is misunderstood by the compiler in the same way as before, and the raw Apple event has to be substituted again. One easy fix is to capture the enumerator as a variable:
set userdomain to user domain
tell application "System Events"
path to application support from userdomain
-- alias "feathers:Users:mattneub:Library:Application Support:"
end tell
An even more robust approach is to use run script to get a second level of evaluation. It's true that run script is expensive, but we can mitigate this somewhat by calling it in a script property initializer, so that the result is obtained just once (until we recompile, of course). The four-letter code appears as a literal string, which has the further advantage of clarifying the purpose of our trickery:
property userdomain : run script ("«constant fldmfldu»")
tell application "System Events"
path to application support from userdomain
-- alias "feathers:Users:mattneub:Library:Application Support:"
end tell
If decompilation of a script runs into trouble, you may see bits and pieces of original Apple events as raw four-letter codes. We saw earlier ("Missing External Referents" in Chapter 3) what happens if an application or scripting addition is present when a script file is compiled but is missing when you open the compiled script file in a script editor application. AppleScript needs the dictionary in order to decompile the script. If a scripting addition is missing, or if AppleScript can't find an application and you nominate some other application, the script opens anyway, but any Apple events that can't be translated into English appear as raw four-letter codes:
tell application "Finder"
get «class euSu» of «class euMS» 1 of «class euMB» "Trash"
end tell
Something similar can happen in the display of a dictionary, if the dictionary is defective. For instance, BBEdit's print settings class has a property cover page whose class is described as lwec (or, in older presentations of the dictionary, «class lwec»). Evidently this refers to some class or enumeration whose definition is missing from the dictionary, so it has to be displayed using its four-letter code. Because the definition is missing, it is impossible to learn what BBEdit expects here.
In a compiled script