Re: Scripter (The Program)
Re: Scripter (The Program)
- Subject: Re: Scripter (The Program)
- From: Richard 23 <email@hidden>
- Date: Fri, 10 Nov 2000 17:11:28 -0800
Bill Cheeseman said:
>
I am always tempted to defer to anything you say about what is legal in
>
AppleScript, Mark, because you know far more about the innards of
>
AppleScript than I. But....
>
>
What it boils down to is whether AppleScript is supposed to tolerate the use
>
of an identifier as a variable name when it is spelled the same as an
>
identifier labeling a handler within the same scope.
You're not looking in the right scope. The scope is the entire script
when you're at the top level, and the current handler unless you use
"my" or expressly identify a variable as being global.
>
The AppleScript Language Guide, p. 27 (in my 1993 edition), says that a
>
variable name and a handler name are both identifiers: "variable names are
>
identifiers.... Identifiers are also used as labels for ... handlers." In
>
your script, the identifier "TestHandler" is used both as a variable and as
>
a label for the handler TestHandler(). Surely this is illegal in
>
AppleScript. Nothing I have seen in the documentation allows overloading of
>
identifiers in this fashion.
No, no, no! Nothing you have seen prohibits the use either!
Here's Mark's example again:
>
on TestHandler(p1)
>
display dialog p1 buttons "OK" default button 1
>
end TestHandler
>
>
on TestHandler2()
>
beep
>
end TestHandler2
>
>
set TestHandler to TestHandler2
>
TestHandler()
Marks example works because when you execute statements in the top-level
all variables are considered global unless expressly declared local.
This often leads to misleading results which can't be replicated when
used in a handler (which is where most of the action usually takes place.)
So TestHandler is already defined as a handler, TestHandler2 is also a
handler. Assigning one handler to another has the effect of replacing
one with another. I do this occasionally at it always works.
>
Your script works in both products if the variable name is changed to
>
something different from the handler name -- for example:
>
>
Set X to TestHandler2
>
X()
But you're missing the point entirely. There what you're doing is to
get a reference to TestHandler2 then you're calling TestHandler2 by
reference through the variable X. Try that within a handler (but not
run or open) and it won't work unless you make X global as it is if
you use it in the top-level.
>
The fact that your script works in Script Editor does not convince me that
>
it is legal. I showed, for example, that Script Editor behaves illegally
>
when running Richard23's script. It seems to me that Scripter is correctly
>
flagging a syntax error in your script.
Arrrggh!
Why would you think that because something doesn't work in Scripter yet
works in the other 5 editors that they are all wrong?
The reason my script WORKS is that I'm assigning a handler to a handler
where you mistakenly thought I was assigning a string to a variable using
the same name as the handler. Try that and you'll kill the handler.
The string would replace the GLOBAL handler and wipe it out.
If you look more closely you'll see I assigned it to "my TestHandler"
and when you use "my" AppleScript looks beyond the current scope (the
current handler) for the first occurrence of the name and uses that.
Look again:
>
on run
>
set my TestHandler to run script "TestHandler
>
on TestHandler(theName)
>
display dialog \"Hello, \" & theName
>
end"
>
TestHandler("R23")
>
end run
>
>
on TestHandler()
>
end TestHandler
"my TestHandler" is the script's handler
run script returns a handler from a generated script object. It's a
little confusing because the return value is specified on the first
line. But it creates a handler and then returns it.
I assign the returned handler to a handler in calling script, replacing
it. Then when the next line calls the handler, it's using the new one.
That's about as clear as I can get and I'll shut up about it now since
we're not getting anywhere!
>
What is your touchstone for legality?
Uh, Apple's Script Editor seems the likely choice.
>
Where is Chris Nebel when we need him?
Probably wisely ignoring this thread!
I know what I'm doing is unconventional and not in the book. I don't
recommend it unless you know what you're doing. I'm sorry I brought it
up, I just wanted to see if the new version of Scripter made the extra
syntax checks optional or if it had been changed in some way before I
considered upgrading.
Apologies to everyone for the confusion. But when in doubt, use Script
Editor. Regardless of what one thinks is right or wrong I think Apple's
Editor has the right to define what is legal and what is not.
R23