[Pythonmac-SIG] appscript terminology caching

[has]

Jack Jansen wrote:

>>>Terminology resources belong to installed applications, not client 
>>>scripts, so it wouldn't make sense to bundle it with the latter. 
>>>(i.e. It's specific to a machine, not to a script.)
>>
>>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.
>
>I agree with this (with Bob, that is). It would be very nice if we 
>could have this same behaviour for Python.

Having not that long ago escaped from the mind-melting mess that is 
AppleScript, I can pretty much guarantee that you _don't_ want Python 
to behave just like AS does. :)

There are a lot of things AppleScript does because it had to make 
severe compromises, mostly due to processor and memory constraints, 
then that we're not forced to make today. There's a lot of other 
mistakes it makes because its designers' ambitions far outstripped 
the existing knowledge and resources available at the time, and which 
were never rectified over time for one reason or another (sudden 
disbandment of the original dev team by management; fundamental flaws 
that can't be foxed short of a 100% redesign+rewrite, etc). So while 
it's a useful source of design lessons, most are lessons in how you 
SHOULDN'T to do things rather than how you should.


>And while we can't in the general case, because there's no "compile 
>step" for Python, it would be good to have it at least for py2app 
>packaged programs.

I assume you're not referring to AS's hideous habit of baking AE 
codes right into the bytecode, but a rather less toxic solution of 
merely attaching a bunch of runtime translation tables to a script, 
yes?

However, I still can't see the value in binding a server 
application's terminology translation tables to client programs. All 
that happens is your system swims with lots of terminology modules 
that may or may not have any relation to the applications that are 
actually installed. Wouldn't it make more sense to have one 
terminology module per installed application?

Another thing to consider: if you're going to have breakage caused by 
a mismatch between the version of application the script was authored 
for and the version of application actually installed, wouldn't it be 
better to break at a higher level, eg:

	Error: application "Foo" doesn't understand command "do_something"

which is what happens when appscript encounters an identifier for 
which no terminology definition exists, rather than:

	Error: application "Foo" doesn't understand <<event FooADsom>>

which happens when aem sends an unrecognised event.


>I'm toying with an idea to abuse Python's import mechanism for this, 
>something along the lines that when you need the terminology for 
>MyApp you import MagicTerminologyGenerator.MyApp, and when 
>MagicTerminologyGenerator/MyApp.pyc exists it'll be used 
>automatically,

There's a problem with that inasmuch as Python identifiers are 
limited to alphanumeric characters, thus you often won't be able to 
use an app's real name, e.g. Acrobat_Reader_5_0 rather than 'Acrobat 
Reader 5.0'. Otherwise I don't see any real advantage in this over 
something like:

	itunes = app('eppc://20.20.20.20/iTunes', usingtermsfrom='iTunes.app')

where the terminology module associated with 'iTunes.app' (presumably 
this association is specified by the user when creating the cached 
terminology) is retrieved as part of the app() constructor's duties.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/