AppleScript_ The Definitive Guide - Matt Neuburg [76]
property x : 5
script myScript
property x : 10
display dialog x
end script
run myScript -- 10
It looks like we can never access the top-level property x from within the script object myScript, because the name x is overshadowed by myScript's own property x. A script object's top-level entities can be accessed by using the name of the script object, as we know. But the script as a whole has no name. But now we know another way to refer to the script as whole—as myScript's parent:
property x : 5
script myScript
property x : 10
display dialog my parent's x
end script
run myScript -- 5
Unfortunately, that trick won't work if myScript has a different parent. In that case the solution is to give the script as a whole a name. You can do this by initializing a top-level property to the value me (see "Me" in Chapter 11).
property topLevel : me
property x : 5
script scriptOne
property x : 10
end script
script scriptTwo
property x : 20
property parent : scriptOne
display dialog topLevel's x
end script
run scriptTwo -- 5
Surprisingly, there's a parent beyond the script as a whole. The script as a whole has as its parent the AppleScript scripting component. This appears to your code as a script object called AppleScript.
The AppleScript script object has some properties that you can access (listed in Chapter 16). Normally you do this without having to refer to AppleScript explicitly, because these properties are in scope globally; it's as if every script were surrounded by another invisible script with property declarations for these properties. But in a context where a name overshadows the name of one of these properties, it would be necessary to be explicit, in order to jump past the current scope and up to the level of AppleScript:
set pi to 3
display dialog pi -- 3
display dialog AppleScript's pi -- 3.141592...
display dialog parent's pi -- 3.141592...
The AppleScript scripting component has a parent too—the current application . This is the host application that summoned the AppleScript scripting component to begin with. The current application is the absolute top of the inheritance chain, and can be referred to in code as current application. For example:
display dialog (get name of current application) -- Script Editor
To sum up:
script myScript
my parent -- «script», the anonymous top level
my parent's parent -- «script AppleScript»
my parent's parent's parent -- current application
end script
run myScript
Non-Script Parent
A script object's parent doesn't have to be a script object. It can be a value of a different type altogether. In that case, the script object suddenly appears to be that other object, in cases where it cannot respond to a message itself. I have never seen this feature employed usefully in code, but it's definitely cool:
script s
property parent : {"Mannie", "Moe", "Jack"}
on greeting( )
return "Howdy"
end greeting
end script
tell s
greeting( ) -- "Howdy"
get item 2 -- "Moe"
end tell
In effect, the script object s is now a kind of list wrapper; it can do things that a list can do, such as report on its items, but it can also respond to the greeting( ) message. However, this trick breaks down against other features of AppleScript; for example, operators treat the script object as a script object, not as a list:
script s
property parent : {"Mannie", "Moe", "Jack"}
end script
get s & "Pep" -- {«script s», "Pep"}, not {"Mannie", "Moe", "Jack", "Pep"}
Handler Calls, Commands, and Script Objects
Several times in this chapter I've pointed out that you don't need to use its (or my) with a handler call when accessing a handler that is a top-level entity of a script object. You do have to use its in order to access the handler as a value. It's the call that gives you access without its.
So, as you know, you can't say this (without its):
script s
property p : 10
end script
tell s
get p
end tell
At runtime, you get an error saying that p is undefined. That's because without