Re: Scripter (The Program)
Re: Scripter (The Program)
- Subject: Re: Scripter (The Program)
- From: Christopher Nebel <email@hidden>
- Date: Fri, 10 Nov 2000 17:28:43 -0800
Greg Strange wrote:
>
> Where is Chris Nebel when we need him?:
>
>
It never ceases to make me giggle when I realise that Chris' last name in
>
German means fog and we look to him for clarity.
It's a coincidence, I swear! I hadn't been reading this thread because I thought you were just arguing about the relative virtues of Scripter, but Doug Korns clued me in.
Bill Cheeseman wrote:
>
What misled you is the fact that Script Editor will compile and run the full
>
script. You misinterpreted the meaning of this when you concluded that it
>
proves your script to be correct. In fact, it demonstrates that Script
>
Editor has a problem. Script Editor executes the Run Script command
>
correctly but then fails to catch the parameter error in the last statement
>
-- even though it does catch the parameter error when the Run Script
>
statement is omitted. ...
>
>
If you were trying to do what programmers might call "overloading" your
>
TestHandler() handler -- that is, to give two different handlers the same
>
name but different parameter lists -- the short answer is that AppleScript
>
simply doesn't support this technique. Other languages do, such as
>
Objective-C, but AppleScript wasn't designed to have these more complex
>
capabilities.
This doesn't happen very often, Bill, but you're dead wrong on this one. AppleScript was designed as a fully dynamic language and does support everything Richard is trying to do; Script Editor does not have a problem; and Scripter's syntax checking is being, shall we say, overenthusiastic in assuming a static view of the world.
Most people don't take advantage of this -- heck, most people don't even know it's possible! -- but handlers are assignable just as properties are. That means that you can change a handler at run time to something completely different, including one that takes a different number of parameters. This is a questionable design practice -- it's difficult to call a handler if you don't know what its interface is -- but it's perfectly legal.
By the way, the last "statement" -- the "on TryHandler()" bit -- is not really a statement, it's a static handler definition. It doesn't get run in response to a "run" command, but only if someone calls it. No one is calling it, because Richard slams a different handler into that slot and then calls that one. No calls, no parameter error. (What happened to the original, you ask? Well, because no one references it anymore, it's garbage, and will disappear after the next collection run.)
--Chris Nebel
AppleScript Engineering