Re: solutions to scripting addition terminology confilicts
Re: solutions to scripting addition terminology confilicts
- Subject: Re: solutions to scripting addition terminology confilicts
- From: "Neal A. Crocker" <email@hidden>
- Date: Sat, 26 Jan 2002 02:08:25 -0800
There've been so many posts on this thread since I checked my email
last night, and so many of them contain things that I want to respond
to that I can't repsond point by point and person by person, so I'll
just sort of generally address a couple of points on the topics
discussed to the list in general:
1) Speed of using osax vs speed of telling appliction:
If an osax and a faceless background application (already running)
were designed to handle the same event in the same way, the osax
would have a (significant, I think) speed advantage because there is
overhead that sending the event to an application incurs.
(Applescript engineering team, correct me if I'm way off). This
overhead results from packaging the event and transporting it between
applications, which possibly involves copying the information several
times from one place in memory to another.
2) Scott Nortons's idea of making "modular" use of osax by separating
their terminology from their code:
As far as violating licenses goes, could I be legally prosecuted for
suggesting that what people do with osaxen on their own computers
without ever distributing the results is their own business? Anyway,
I think this may have already been mentioned, but let say it just in
case. The "using terms from" statement will take an alias to a file
with an aete resource as an argument and will compile the code inside
its block against the terminology defined by the aete. In fact, the
file can be nothing but a resource fork holding just an aete
resource. Building on Scotton Norton's idea, an adventurous,
resource savvy scripter could implement his/her own module system by
a) stripping the aetes from oxen,
b) eaving the aete-less osax in the "Scripting Additions" folder and
c) putting the aetes (as resources in the resource forks of
othewise empty files) in some convenient folder, such as "Scripting
Terminologies" folder.
The net result: a clutter-free, global, applescript namespace where
needed terminolgy can be made use with a "using terms from" block.
This slightly extended version of Scott's idea solves the terminology
conflict problem, but it has several drawbacks. First, it requires a
great deal of potentially license-violating work by a scripter that
wants to implement it. Second, it leaves the system appleevent
handler table (where osaxen put their handlers) cluttered with
handlers that may not be used by all scripts. This is both inelegant
and a probable source of significant overhead to an executing script
that uses system handlers. (In fact, this problem is magnified under
OS X, since, to the best of my understanding, under OS X, every
application that executes a script has its own system handler table
and it own copy of every event handler supplied by every osaxen).
Given these drawbacks, I propose an alternative, somewhat similar,
scripting "module" scheme that would require some work by an
adventurous, community-minded osax developer (should I volunteer my
own novice services?):
a) Put scripting additions in a "Scripting Modules" folder,
rather than the "Scripting Additions" folder, so that their handlers
won't be automatically loaded.
b) Make use of a scripting addition (that the putative osax
developer would have to develop) that has two events, one which
causes a scripting addition file in the "Scripting Modules" folder to
load and one which causes it to unload. The events in this
loading/unloading osax would take aliases to scripting additions as
arguments (unless the osax developer wanted to implement some
resolution scheme).
c) To compile against a "module", make use of a "using terms
from" block.
d) To insure that event handlers are in place for applescript
code compiled against a module's terminology, use the load event
handler (possibly at the beginning of the "using terms from" block)
to cause it to load.
e) Clean up after yourself with the unload event handler
(possibly at the end of the "using terms from" block).
Any osax developer's interested?
Neal.