• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: solutions to scripting addition terminology confilicts
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


  • Follow-Ups:
    • Re: solutions to scripting addition terminology conflicts
      • From: JollyRoger <email@hidden>
    • Re: solutions to scripting addition terminology conflicts
      • From: JollyRoger <email@hidden>
  • Prev by Date: another Scripting Mail.app question
  • Next by Date: Re: Scripting Mail.app
  • Previous by thread: Re: Save a text file
  • Next by thread: Re: solutions to scripting addition terminology conflicts
  • Index(es):
    • Date
    • Thread