AppleScript_ The Definitive Guide - Matt Neuburg [82]
{what} for greet
The nitty-gritty of how a handler's definition states how many parameters there are, and how a corresponding call to that handler must be phrased, is remarkably complicated. There are actually four cases that must be distinguished (though you are most likely to use only the first two in handlers that you define). I'll discuss these four cases in a moment, but first I want to talk about the problem of optional parameters.
Optional Parameters
Officially, there is no way to declare a parameter optional in AppleScript. On the other hand, you really don't need a way to do this, because a parameter can be a list or a record, which can have any number of items. (Gosh, all we need is a shift command and this would be Perl!)
For example, here's a handler that calculates the area of a rectangle given the lengths of the two sides. If you pass the length of only one side, the rectangle is assumed to be a square:
on area(L)
set a to item 1 of L
if (count L) = 2 then
set b to item 2 of L
else
set b to item 1 of L
end if
return a * b
end area
area({3, 4}) -- 12
area({3}) --9
A record used as a parameter is often an even better way to simulate optional parameters because it allows you to simulate default values for missing parameters as well. A single concatenation lets you merge the defaults into the parameter record without upsetting the values that are already there (see "Record" in Chapter 13; use of this device in this context was suggested to me by Scott Babcock). For example:
on greet(R)
set defaults to {greeting:"Hello", whom:"World"}
set R to R & defaults
display dialog R's greeting & ", " & R's whom & "!"
end greet
greet({whom:"Everybody"}) -- Hello, Everybody!
greet({greeting:"Howdy"}) -- Howdy, World!
greet({greeting:"Bonjour", whom:"Monde"}) -- Bonjour, Monde!
greet({}) --Hello, World!
It is not an error to include extra parameters in a handler call. They are simply ignored by the handler. You might think this feature would be useless, but it's not. It allows the caller to be somewhat ignorant of the details of the handler it's calling. This is valuable particularly when the caller and the handler are written by two different people. Suppose, for example, that I'm a script runner and you are supplying the script for me to run. I can specify in the documentation that I'm going to call the person handler in your script, with four parameters: firstName, lastName, age, and place. You can define your person handler, omitting any parameters that you happen not to care about. So, I might call your handler like this:
person given firstName:"Matt", lastName:"Neuburg", age:51, place:"Ojai"
But you might define your handler like this:
on person given firstName:fir, lastName:las
display dialog fir & space & las
end person
That's legal. (The application Phlink actually works like this; see Chapter 26.)
No Parameters
If a handler takes no parameters, the name of the handler in the definition is followed by empty parentheses:
on handlerWithNoParameters( )
-- code
end handlerWithNoParameters
The call consists of the name of the handler followed by empty parentheses:
handlerWithNoParameters( )
Positional Parameters
Positional parameters are unnamed . The pairing between each parameter value passed and the local variable in the handler that receives it is performed by looking at their respective positions: the first parameter is assigned to the first variable, the second parameter is assigned to second variable, and so forth.
If a handler takes positional parameters , the name of the handler in the definition is followed by one or more variable names in parentheses, separated by commas:
on handlerWithOneParameter(x)
-- code
end handlerWithOneParameter
on handlerWithFourParameters(a, b, c, d)
-- code
end handlerWithFourParameters
The call then consists of the name of the handler followed by parentheses containing the parameter value or values, separated by commas:
handlerWithOneParameter(7)
handlerWithFourParameters("hey", "ho", "hey",