AppleScript_ The Definitive Guide - Matt Neuburg [74]
In that example, we told the child from outside to execute a handler that it doesn't have but the parent does. The child can also tell itself to execute such a handler:
script mommy
on talk( )
display dialog "How do you do?"
end talk
end script
script baby
property parent : mommy
talk( )
end script
run baby -- How do you do?
Getting and setting properties works the same way. In this example, we get and set the value of a property of baby that baby doesn't have:
script mommy
property address : "123 Main Street"
end script
script baby
property parent : mommy
end script
display dialog baby's address -- 123 Main Street
set baby's address to "234 Chestnut Street"
display dialog mommy's address -- 234 Chestnut Street
Again, the same thing can be done from code within the child; but now the name of the property must be prefixed with the keyword my. Like its when targeting a script object, my specifies that we're talking about a top-level entity of this script. (In fact, instead of my, you can use its; but that seems less intuitive, somehow.)
script mommy
property address : "123 Main Street"
end script
script baby
property parent : mommy
on tellAddress( )
display dialog my address
end tellAddress
end script
baby's tellAddress( ) -- 123 Main Street
Similarly, we can refer to a script object that the child doesn't have but the parent does:
script mommy
script talk
display dialog "How do you do?"
end script
end script
script baby
property parent : mommy
end script
run baby's talk -- How do you do?
Again, if the child wants to do this, it must use my (or its):
script mommy
script talk
display dialog "How do you do?"
end script
end script
script baby
property parent : mommy
run my talk
end script
run baby -- How do you do?
With a handler call, there is no need for my:
script mommy
on talk( )
display dialog "How do you do?"
end talk
end script
script baby
property parent : mommy
talk( )
end script
run baby -- How do you do?
Polymorphism
When code within a script object refers to a top-level entity, the search for this top-level entity starts in the script object to which the message that caused this code to run was originally sent. This is called polymorphism . Again, when accessing a property or script object, you must use the keyword my (or its) to get polymorphism to operate.
An example will clarify:
script mommy
on tellWeight( )
display dialog my weight
end tellWeight
end script
script baby
property parent : mommy
property weight : "9 pounds"
end script
baby's tellWeight( ) -- 9 pounds
We ask baby to tell us its weight, but baby doesn't know how to do this (a baby can't talk), so the message is passed along to the parent, mommy. There is now an attempt to access my weight. But mommy has no weight property. However, the search for weight starts with baby, because our original message was to baby (mommy is involved only because of inheritance). The property is found and the code works.
If we take away my, polymorphism fails to operate and the entire mechanism breaks down. With the previous example, we would get a runtime error message: "The variable weight is not defined." Without my, the name weight is not an attempt to access a top-level entity. Instead, it's just a name. AppleScript looks for a defined variable weight in scope at the point where the name is used, and fails to find it.
The reason for the "poly" in the name "polymorphism" is that the response to the parent's use of a term can mean different things, depending on who the original target was. A parent whose code is running because of inheritance has no idea of this fact, so it has no idea exactly what its own code will do. This is officially cool, and is one of the key principles of object-based programming. For example:
script mommy
property weight : "120 pounds"
on tellWeight( )
display dialog my weight
end tellWeight
end script
script baby
property parent : mommy
property weight : "9 pounds"
end script
script baby2
property parent : mommy
property