AppleScript_ The Definitive Guide - Matt Neuburg [146]
Differences between an application's implementation of an operator and AppleScript's implementation can arise under these circumstances. This seems rather scary, but if the application is well-behaved, these differences should be minor. The primary case in point is the use of considering clauses. For example:
tell application "Finder"
considering case
name of every folder whose name contains "E"
end considering
end tell
-- {"emptyFolder", "Test Me"}
The Finder gives the wrong answer; if you consider case, neither of these folder names contains "E". The Finder is simply ignoring the considering clause. In fact, I don't know of any application that considers considering clauses in a string comparison. (See "String Considerations" in Chapter 19.)
The workaround in a situation like this is a two-step approach: fetch all the values and then have AppleScript perform the test itself. AppleScript does not implement boolean test element specifiers for lists, so the test must be performed as a loop:
tell application "Finder"
set L to name of every folder
end tell
set L2 to {}
considering case
repeat with aName in L
if aName contains "E" then
set end of L2 to contents of aName
end if
end repeat
end considering
After that, L2 contains the right answer. Fortunately, such an approach is not particularly expensive in this case; luckily, the Finder implements get name of every (see "Operations on Multiple References" in Chapter 11), and the test we perform in the loop doesn't involve sending any Apple events.
Chapter 16. Global Properties
AppleScript's global properties are essentially predefined variables; they are named values that exist automatically, without your code having to define them. Your code can access them because they are in scope in every script, thanks to the inheritance mechanism (see "Inheritance" in Chapter 8). Your script as a whole is a script object whose parent, by default, is another script object called AppleScript, which represents the AppleScript scripting component instance. These predefined variables are properties of the AppleScript script object. Thus the inheritance mechanism makes them global; no matter where you are when you access one of them, it is sought as a top-level entity up the parent chain until the AppleScript script object is reached. Even if the name of a global property is overshadowed in some scope of your script, it can still be accessed through the name AppleScript. For example:
property pi : 3
AppleScript's pi -- 3.14159265359
The global properties are like any other script properties, and as such:
They are settable.
Their values are shared by all scripts running under this instance of the AppleScript scripting component.
They persist along with this instance of the AppleScript scripting component.
The status of the global script properties is thus somewhat counterintuitive. You might have thought values such as pi and tab would remain constant. That's not the case. You can change the value of one of them, and then this script and any other scripts that run under the same AppleScript scripting component instance will share this new value. This mechanism introduces a certain fragility, because if a script assumes that these properties always have their default values, it can break. The only thing standing between you, the programmer, and this fragility is a sort of tacit agreement about which global script properties it is customary to change. It is common practice to change the value of the text item delimiters; it is not common practice to change things like pi or tab. This is rather a silly state of affairs but there's nothing that can be done about it now.
Warning
If you really, really want to, you can completely cut off your own access to the global properties: you can overshadow all their names, overshadow the name AppleScript, and alter the parent chain. So Don't Do That.