solutions to scripting addition terminology confilicts (i.e. the osax namespace problem)
solutions to scripting addition terminology confilicts (i.e. the osax namespace problem)
- Subject: solutions to scripting addition terminology confilicts (i.e. the osax namespace problem)
- From: "Neal A. Crocker" <email@hidden>
- Date: Mon, 21 Jan 2002 01:02:42 -0800
I propose three alternative solutions to the problem of scripting
addition terminology conflicts. Each solution would require slight
(as far I can determine) modifications to Applescript that would have
to be implemented by the Applescript Engineering team, since third
party scripting additions writers don't have the necessary access,
but I'm posting them here to see what sort of response they get from
people who use applescript.
Solution 1: The introduction of a "using module" block and a
"Scripting Modules" folder.
A "using module" block would be similar to a "using terms
from" block, in that the dictionary of the module specified by the
"using module" statement would be used to compile statements inside
the block. One extra thing that the "using module" module block
would do would be to cause the loading (and subsequent unloading) of
"modules". Modules would be nothing more or less than scripting
additings stored in a "Scripting Modules" folder, rather than the
Scripting Additions folder. Unlike Scripting Additions, they would
not be automatically loaded by the "Master Loader" (or whatever it is
that loads scripting additions and makes them available to
applications compiling and executing scripts). Instead, they would
be loaded only when scripts call on them with the "using module"
statement.
Note that a "using module" statement could be implemented in
such a way as to allow hierarchical module naming (like perl modules
or java packages). Modules could be specificied using paths relative
to the "Scripting Modules" folder. A module specification of "blah"
would identify a module file named "blah" in the "Scripting Modules"
folder, while a module specification of "blah:ugh" would identify a
module file named "ugh" in the "blah" subfolder of the "Scripting
Modules" folder. If a the module "blah" were specified and blah were
a folder in the "Scripting Modules" folder, rather than a file, all
the modules in blah would be loaded
One more note: In addition to using modules stored in the
Scripting Modules folder as arguments of the "using module"
statement, a scripter ought to be able to use an alias to a scripting
addition file stored in some irregular locations, just as he/she can
with the "using terms from" statement. Determining what the load and
where to get the aete in such a case would be a trivial task for the
"using module" block. The alias used as the argument provides all
the necessary info.
By the way, the term "module" is very "programmery" (to
borrow an adjective coined by someone on an applescript-related
list), and, thus, not in keeping with "plain-language" (almost said
"plain-english", by force of habbit) standard of applescript. Thus,
probably, an alterntive term would have to be devised.
Solution 2: Modification of the "using terms from" statment to allow
expressions as arguments that would be evaluated at compile time.
As far as I can tell, the "using terms from" statement
accepts arguments only in two forms: 'application "foobar"' and
'alias "HD:blah:ugh"' (at least in OS 10.1.2, AS 1.8.1). This means
that terminolgy sources have to be hardwired into a script before
compile time, with no possibity for any useful slight-of-hand by an
osax writer. Consider the property declaration statement 'property
myprop : expression-for-initial-value'. I've noticed that exressions
involving osax events, such as the 'path to' event in the Standard
Additions. are evaluated at the time of compilation to give the
property its intial value. Imagine what could be done if the "using
terms from" statement were to accept compile-time-evaluated
expressions as arguments. An osax writer could create an event called
"module" that would return and alias to a scripting addition file
stored somewhere besides the Scripting Additions folder. If the
event also took the trouble to load the scripting addition called as
its argument, an osax write could actually implement a module
loading mechanism similar Solution 1 described above.
Solutions 3: Introduction of a mechanism for third-party Applescript
extenders to extend Applescript's compile-time behavior
Beare with me here, since this may take a little explaining.
Applescript already has several language elements resulting in action
at the time of compilation: the property declaration statement that
evaluates the initial value expression at compile time, sending any
necessary events, the script definition block that is evaluated at
compile time, the "using terms from" block that loads terminology at
compile time for interpretation of statements contained within, and
the 'application "blah"' and 'alias "HD:foo:bar"' expressions which
are evaluated at compile time. Currently, applescript extenders can
only create language elements (i.e. events, etc.. defined by osaxen)
that are evaluated at execution time (unless incorporated within
property declaration statements, where their compile time effects are
of limited use). If third party applescript extenders had a
mechanism for extening the compile time behavior of applescript, they
could implement Solution 1 (described above), or other creative
solutions, to the osax namespace problem without intervention from
the Applescript Engineering team. Just as food for thought, one way
to implement a mechanism for compile-time behaviors might be to
somehow allow the designation of events defined by osaxen as
"to-be-evaluated-at-compile-time" and/or
"to-be-evaluated-at-run-time". If such were possible, an osax writer
could concievably invent a "using module" event that behaved much as
described the the "using module" statement proposed in Solution 1
described above. (Of course, the Applescript Engineering team would
also have to provide the event writer a way of passing to the
applescript scripting component an aete during compile time which it
intended to be used for compilation of a part of the script. In
other words, a way would have to be provided for an event evaluated
at compile time to act as a "using terms from" statement).
Now, as Michael Myers of Saturday Night Live says in the role of one
of his standard characters (can't remember the name...), "Discuss
amongst yourselves...".
Thanks,
Neal.