True Optional Handler Parameters (Positional)
True Optional Handler Parameters (Positional)
- Subject: True Optional Handler Parameters (Positional)
- From: Michael Terry <email@hidden>
- Date: Sun, 22 Feb 2004 17:09:11 -0800
Have you ever wanted to include optional parameters, but were stymied
by AppleScript's seeming lack?
As a novice, it quickly becomes clear that you can't do something like
this:
on showArgs(args)
repeat with i in args
display dialog i
end repeat
end showArgs
showArgs()
--> {} doesn't match the parameters {args} for showArgs.
showArgs("jello")
--> j
--> e
--> l
--> l
--> o
Oops!
Then you might have stumbled across the following, inspiring a sliver
of hope:
showArgs("jello","brand","gelatin")
--> j
--> e
--> l
--> l
--> o
Oops, again, but at least there wasn't an error. How to get the other
arguments? After beating your head against the wall for a few minutes
(or hours, if you're like me), you gave up that approach as a loss.
But you didn't give up the feeling that AS is just inconsistent enough
to provide an opening, if only you can find it. What about labeled
handlers? AppleScript's own command handlers have optional
parameters--maybe lowly scripters can use them, too. The ASLG doesn't
mention anything about it, but you try anyway:
on sayEachArg of args given voice:name
try
name
on error
set name to "Victoria"
end try
repeat with i in args
say i using name
end repeat
end sayEachArg
sayEachArg of {"Hello", "there"} given voice:"Hysterical"
Of course that works, but now the real test:
sayEachArg of {"Hello", "there"}
--> Can't get sayEachArg of {"Hello", "there"}.
Awwww, man. OK, well, can you at least override the AS's built-in
command handlers that already have optional parameters?
on display dialog msg default answer txt
try
txt
on error
set txt to "I'm missing something here."
end try
continue display dialog msg default answer txt
end display dialog
display dialog "Hello"
--> The default answer parameter is missing for display dialog.
Now you resort to less-nice workarounds. You can always pass an
explicit list as a single handler argument. Or you can simulate labeled
optional parameters:
on saveScript(args)
set {s:s, p:p, r:r, b:b} to args & {s:me, p:":tmp:tmp", r:false,
b:false}
tell (store script s in p replacing r) to if b then tell AppleScript
to beep
end saveScript
saveScript({})
--> current script saved in /tmp/tmp
saveScript({p:":tmp:tmp2"})
--> current script saved in /tmp/tmp2
saveScript({p:":tmp:tmp2"})
--> error: Duplicate file name. file :tmp:tmp2
saveScript({p:":tmp:tmp2", r:true})
--> current script saved over /tmp/tmp2
script NoPurpose
property name : "No Purpose"
property class : "Haven't Any"
end script
saveScript({p:":tmp:tmp2", s:NoPurpose, r:true, b:true})
--> script WithNoPurpose saved over /tmp/tmp2 with notification
Well, that's not too bad if you don't mind wordy labeled parameters,
but I promised True Optional Handler Parameters in the subject. Here's
one example of how you could define your handler:
property nil : run script "((ASCII character 0)'s{it,it,it,it}as
text)'s{it,it}"
on nullifyCodes of everyFile without theAidOfThisVariable
if everyFile is {} then set everyFile to choose file
tell application "Finder" to repeat with f in everyFile as item as list
set {f's file type, f's creator type} to nil
end repeat
end nullifyCodes
nullifyCodes()
nullifyCodes(choose file, choose file, choose file)
nullifyCodes(files of item (choose folder) of application "Finder")
You define your handler as a labeled type which must have a direct
object using ( in | of ) followed by the argument variable. After that,
you can call your handler in the popular way, and the arguments will be
smooshed into an argument list that can be accessed via the variable
name specified as the direct object in the handler definition.
Note that when you call a labeled handler as positional, variables
after the direct object will be undefined. If you intend to mix call
styles, you'll have to trap undefined values.
I can think of lots of uses for this--I'm sure you can too. For
example, as above, you can ask the user for input if none is given when
called. Or you can preserve backward compatibility with regard to
library interfaces while the library continues to evolve.
Mike
"Perl started out as just a text processing language--a better awk and
sed--but it very rapidly spread to the ecological niche of system
administration. On Unix, at least, a lot of system administration is
text processing."
--Larry Wall
<
http://interviews.slashdot.org/interviews/02/09/06/1343222.shtml?
tid=145>
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.