[Pythonmac-SIG] appscript terminology caching

[Paul Berkowitz]

On 10/15/04 1:56 PM, "Bob Ippolito" <bob at redivi.com> wrote:

> I'm not sure I agree with this.  I'm pretty sure that compiled
> applescripts do not depend on the terminology of the applications they
> talk to, and I would imagine that the vast majority of applications
> written in compiled languages that use AppleScript to talk to one
> another do not parse terminologies before they start talking.

Absolutely they do. It's not something you "agree to" or not. It's a fact.
Compiled applescripts DO depend on the terminology of the applications they
talk to.

Behind every keyword in AppleScript lies a hidden "raw code" which is the
real command. class or property. It appears in its own right as
«guillemets», like that. They are always «class xxxx» - 4 characters, or
«event xxxxxxxx».- 8 characters. There are all sorts of rules about them,
such as that only Apple can use all lower-case. There are some English
keywords belonging to the AppleScript language itself. which will always
compile and decompile. But keywords belonging to an application will only
compile and decompile within a "tell application" block, and where the
application has to be present on the machine. If a script has been properly
compiled, it will not decompile or run on another machine if it can't find
an application of the correct name. What you seen then, if you open it in a
script editor, are the raw codes. And the script will not run. It asks the
user where the application in question is, and if the user cannot find it
correctly (it may be under another name), it fails.  As has mentioned,
there's a clever 'using terms from' block you can use when you compile a
script that lets you direct a tell block to an application by variable. That
allows the script to compile (with raw codes) on another machine, and if the
script is designed to allow the Finder to find the application, under
whatever name, by its creator code or CFBundleIdentifier in a plist, it will
run.

I'm startled that someone of your acuity in your own area, Python, would
imagine that has doesn't know what he's talking about in AppleScript. He's
an expert, one of the very, very few who knows its inner workings. Unless
you somehow know better for certain, I think that a good working policy
would be to take has's word for everything to do with how AppleScript works.

-- 
Paul Berkowitz
(an AppleScripter)