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: Mon, 21 Jan 2002 14:42:55 -0800
Date: Mon, 21 Jan 2002 10:36:58 +0000
Subject: Re: solutions to scripting addition terminology confilicts
(i.e. the osax namespace problem)
From: Simon Forster <email@hidden>
To: Applescript List <email@hidden>
On Monday, January 21, 2002, at 09:02 am, Neal A. Crocker wrote:
I propose three alternative solutions to the problem of scripting
addition terminology conflicts.
Which presupposes that scripting additions are a good thing.
By creating an AppleScript scripting addition as opposed to an
application, what do you gain? Scripting additions extend AppleScript's
language which, from this naive users perspective, means that coercions
happen auto-magically so I don't need to use explicit tell blocks.
That's about it. Is this a good thing? I'd answer no.
1) There's only one global namespace so we start getting naming
conflicts if everything's written as a scripting addition.
2) Code becomes more obtuse as funky things are happening on the sly.
Look at the frequent postings we see where some scripting addition or
the other is performing an unseen coercion leading to unexpected
behaviour on different machines.
OK, with 1) we're in danger of starting a circular argument. So, let's
simply say that by reducing our reliance on scripting additions and
using faceless background applications instead, the problems you're
trying to address go away all by themselves!
Actually, with 2), we're in as much danger of starting a cicular
argument. Using the scheme I proposed, take a scripting addition,
put it in the "Scripting Modules" folder, and it won't be
automatically loaded. It will be treated as a module, instead.
Unless you specifically "call" it with a "using module" block, its
terminology, events and coercions might as well not exist as far as
you're script is concerned. If you do use a "using module" block to
call on it, its terminolgy, events and coercions are available ONLY
inside the block (between the "using module" and "end using module"
statements), just like with a tell block and an application,
faceless-background or otherwise.
So, this brings up the question of how, exactly, a module would
differ from a faceless background application and the resulting
advantages and disadvantages. As indicated by JollyRoger, scripting
modules, which are just scripting additions that have to be
explicitly called upon, don't cause a whole new application to start
up. This means they can be faster.
Subject: Re: solutions to scripting addition terminology conflicts (i.e.
the osax namespace problem)
From: JollyRoger <email@hidden>
On 1/21/2002 4:36 AM, "Simon Forster" <email@hidden> wrote:
> Death to scripting additions! Long live faceless background applications!
Word. The only pro-scripting-addition argument I have heard to the contrary
that *might* hold water is that calling scripting additions doesn't cause an
application to launch, and is therefore faster. But the benefits far
outweigh that side-effect, if you ask me.
JR
On the other hand, it means that the application executing the script
has to do all the work. All a scripting addition does is provide
executable code for application to use when the script calls on one
of the addition's coercions or sends one of its events. A faceless
background application, when called upon by a script, uses its own
resources (cpu time and memory), rather than the resources of the
application running the script, to handle the request. This can be a
useful feature, since it allows a limited sort of parallel
processing, but what if many scripts are competing for its attention
simultaneously? A faceless background application creates a
processing bottleneck that scripting additions/modules don't/woudn't.
There's another significant difference between scripting additions
and faceless background applications. To the best of my knowledge as
a novice scripting addition writer, standard dogma for scripting
addition writers is that scripting additions can't create an object
model, while faceless background applications can. In other words,
an image manipulation addition couldn't cause the application running
the script (i.e. the "current application", which is the implied tell
target in the absence of a tell statement) to have elements of class
picture, where each picture had elements of class pixel, each of
which has properties "red intensity", "green intensity" and "blue
intensity". A scripting addition might be able to mock-up a sort of
object module like this using events and "classes" which are really
records, but there would definitely be cracks in the facade that
would potentially make writing scripts a mine-field of confusion if
the script writer tried to take advantage of how objects in
applescript work. One particularly obvious example would be if a
scripting addition defined a "pixel" event with a "of picture"
parameter that returned a record such as "{class:pixel, red
intensity:r, green intensity:g, blue intensity:b}" (where r, g and b
are numbers). The event would be called with a statment such as
"pixel x of picture y", where y is something that could be treated as
a picture and x is a number identifying the pixel of interest. By
defining an event this way, a scripting addition would give the
impression that it had defined an object hierarchy involving pictures
and pixels, but then a script writer might be tempted to write a
statment like "picture y's pixel x". This would be a perfectly valid
alternative to "pixel x of picture y" for a true object model, but no
for an event called "pixel". Faceless background applications are,
of course, applications and can define object hierarchies.
Death to scripting additions! Long live faceless background applications!
I say that scripting additions and faceless background applications
as "extentions" of applescript both have their places depending on
issues such as which application should be doing the work, whether or
not a processing bottleneck is likely and whether an object model
needs to be introduced. Scripting modules wouud be far nicer than
scripting additions because the script writer could control whether
they are used, but they would still have the advantages of scripting
additions over faceless background applications. That said, as far
as I understand, Apple does discourage (at least mildly) would-be
developers of applescript extensions to make faceless background apps
rather than scripting additions. (Aside from terminology conflicts,
there are, as far as I understand it, some behind-the-scenes issues
about the mechanics of scripting additions that potentially allow
them to stomp all over each other [in which case, the last one loaded
wins] and possibly even applications that excecute scripts.)
Simon Forster
Neal.