Re: Handlers in list
Re: Handlers in list
- Subject: Re: Handlers in list
- From: "Neal A. Crocker" <email@hidden>
- Date: Tue, 24 Apr 2001 13:10:00 -0500
...... A handler without arguments is a thing that can be
returned as a value and assigned to a variable. But that variable
can be called
as a handler with arguments only under certain circumstances (if its a global
variable, or if it was previously defined as a handler already, both of which
give it proper scope.)
> Where is all this documented? I can't find anything about it in
> Applescript Language Guide
It really seems like something that is just a fluke of the implementation, and
may go away the way "item 0 of someList" did something weird and
then went away.
The behavior of handler names was determined by experiment, not by
documentation.
Unfortunately, you're probably right that it will go away. Darn!
The safe way, I think, to do this, is to pass a script object and not a nekkid
handler. Script objects are legitimate, ASLG-approved things to assign to
variables, and calling their handlers is clear and straightforward.
script case1
on crevitate()
display dialog "Do whatever is needed"
end process
end script
script case2
on crevitate()
display dialog "Do something else needed"
end process
end script
script case3
on crevitate()
display dialog "Ditto."
end process
end script
set choices to {case1, case2, case3}
tell (some item of choices) to crevitate()
It keeps the conceptual distinction between assigning an object to a variable
and executing a handler clear. Objects are nouns, and its natural
put them into
variables. Handlers are verbs, and its unnatural to see them as something to
store, but natural to see them as doing something when called. Its
also natural
to see an object (a noun) as something that can be activated in some way,
causing it to do one of its actions (verbs, or handlers).
In some sense, the object = noun, handler = verb metaphore makes
sense, but, then again, "there's more than one metaphore to skin a
cat", he said, mixing cats :) For instance, C++ allows a really
wonderful construct called a function object. A function object is
an object of a class where the "()", or "call as function", operator
has been defined so that object can be treated as if it were a
function. This is really nifty because one can do things like create
a class that can be wrapped around two-argument functions, which
stores one argument as an object property, gets the second argument
by being called as a one-argument function, and passed both values to
a the two-argument function it wraps. A trivial expample would be
such an object stored in a variable called add1 which wraps around
the function add(x,y). add1 could be treated as a funcition with the
statement result = add1(x). the "()" operator of add1's class would
return the value generated by add(x,1).
Handlers in Applescript can be passed around as objects and treated
as functions like a C++ function object, but they can't store values
as properties. Darn! This makes them more like C functions. Script
objects in Applescript are more like C++ object which don't have the
"()" operator defined so that they can be treated as functions. Darn
again!. C++ function objects are just plain elegant.