Re: Scripter (The Program)
Re: Scripter (The Program)
- Subject: Re: Scripter (The Program)
- From: email@hidden (Cal)
- Date: Mon, 13 Nov 2000 20:37:30 -0500
Yawn...stretch...oh yeah...there's a world out there. Wha'? You woke me
up out of my hibernation for this? :^)
I will repeat Scott's warning label on this message (and I request that
anyone who continues this thread do so each time they post):
Warning: This thread has wandered off into obtuse language issues,
of interest only to propeller-head programmers, and not relevant to
most scripters. If you use AppleScript to automate your workflow,
make your newspaper publish itself, or set up your school's computer
lab, ignore this thread. But if you think Church numerals reveal the
higher truths of the universe, put on your pocket protector and jump in.
Okay, here's the scoop on the dynamic handler issue.
- Using obscure undocumented features
[This comment is not related to any particular behavior in AppleScript.]
The appearance on the part of a technology implementation of the good
behavior of a particular feature is no guarantee that the behavior will
remain intact forever.
I feel assured that anything that's documented or in widespread use isn't
likely to change in the future. However, IMO there's no guarantee that
undocumented or unintended behavior used by a couple of people won't
change. I would say that relying on obscure behavior that isn't documented
as part of a published definition is risky.
- Helping the scripter
Let me share a story with you. in '93 or '94, when Scripter was in the
alpha or beta testing phase, one of our testers, who was also testing
another editor, complained that Scripter had erroneously reported that the
number of parameters in his call didn't match the number on his
declaration. Here was the situation. (I can't remember the specific
handler or parameter names, but here's what he was doing.) What you see
here was in the middle of a large script (over 500 lines), containing many
handlers and a big top-level:
to ReportError(messageText, messageNum)
-- body of handler
end ReportError
try
-- some stuff here
on error errMsg number errNum
ReportError("The error reported is , errorNum")
end try
As you can see, he had misplaced his closing quotation mark on the call,
which is perfectly legal AppleScript syntactically, but which would never
run properly, if the handler ever tried to use the parameter messageNum.
It should have read:
ReportError("The error reported is ", errorNum)
The script compiled and appeared to run in every editor in existence at the
time, except Scripter. I wrote him back that he had a different number of
parameters on the call than he had on the declaration. (At the time,
Scripter wasn't reporting which line the error was attributed to.) He
insisted I was wrong; we wrote back and forth several times over the course
of a couple of weeks; he walked away angrily.
I'll never know how long he ran his script before the part of his handler
that used the error number was called (it would still work if the handler
was called, so long as the handler never executed any command that would
rely upon the second parameter). I can only imagine that it happened to
him in the middle of a production run somewhere.
Scripter's error checking has saved people's butts more times than you
might imagine. This particular message has been among those with the most
positive impact.
- Dynamic reassignment
[Now to the specific issue.]
Technically, the AppleScript technology allows reassignment of certain
things that are defined in source code. The dynamic aspects of using
replaceable things that are defined in scripts presents certain
"interesting" technical situations.
As I've said before on this list, my goal with Scripter is to facilitate
the largest number of people in being effective scripters. In order to
create the experience for the 99.9% of Scripter users, a couple of
side-effects have occurred in what I would call "fringe" areas. My aim is
to support those things that are stated as part of AppleScript. (There are
one or two things that Scripter can't support.) Also, keep in mind that
some of what Scripter provides goes beyond just that which is required to
support it; often Scripter goes deeper to help facilitate better scripting.
Richard, I'm truly sorry if this inconveniences you. There are a number of
behaviors that AppleScript does (or appears to do) that aren't documented
-- some of these are by-products of how AppleScript is implemented, some
are intentional, and some are unintended and will be fixed later. If I am
able to support those, I will, but I cannot guarantee support for every one
of those things that AppleScript does (or appears to do, depending on the
case) that isn't part of the language definition. It's not reasonable to
require me to do so.
And even those it's allowed, there's just something that feels "off" to me
about having a script containing an explicit declaration of a handler's
interface and behavior (parameters and commands), and then somewhere else
in the script, that handler's interface and behavior gets reassigned. So
at any given point in the script when you look at a call to that handler,
you aren't assured that a handler will do what it says it does by reading
its commands. [And I'm not sure that the code (and yes, I'm breaking my
rule about using the word "code" here, because we're deep into programming
technique with this) would be understandable to anyone reading the script
other than the person who wrote it.]
I just my little old opinion, but when I see a handler call, I want to know
that that the handler I see defined in the script will show me what will
happen when the handler is called.
- Relaxing the parameter checking?
If I relax the rule to have the parameters match, a very, very, very small
number of people (probably less than 5, definitely less than 10) who are
doing something obtuse, undocumented, and rare, will be served, and many.
many, many more people (thousands) will have their experience degraded. If
we allowed parameter count mismatches, the quality of scripts produced by
Scripter users would be degraded, making many of the users of those scripts
unhappy. Moreover, if we relaxed this rule, it'd be impossible to let you
debug the actual handler.
If you're one of those 5 people, please don't jump on me about my use of
the word "fringe". In terms of the bell curve of use, you're way, way out
in the tail (evidenced by the warning Scott posted). Should it turn out
that you are one of the scarce few for whom this presents difficulty, I
humbly apologize. That said, if this affects you, I'd welcome a discussion
-- in private email, please -- to discuss the ramifications of this and the
possibility of a resolution.
Respectfully,
Cal