Re: solutions to scripting addition terminology confilicts
Re: solutions to scripting addition terminology confilicts
- Subject: Re: solutions to scripting addition terminology confilicts
- From: email@hidden
- Date: Mon, 28 Jan 2002 22:22:44 -0500
On Sun, 27 Jan 2002 00:31:53 +0000, has <email@hidden> wrote,
>
Neal A. Crocker wrote:
>
>
>2) Scott Nortons's idea of making "modular" use of osax by separating
>
>their terminology from their code:
>
>
Scott's hack is quite ingenious and I doff my cap alongside everyone else,
>
but ultimately it's a non-standard, unofficial hack - meaning it's a world
>
away from being a viable 'real world' solution, IMHO.
I'm not sure how non-standard and unofficial what I proposed was. It uses the
standard Apple Event dispatch mechanism--if this changes, all Scripting
Additions stop working. It uses a standard AppleScript language construct:
'using terms from', exactly as it was meant to be used. The concept of a
terminology-only component is not new, and is used by Apple in their Folder
Actions.
>
Any fundamental change to the way osaxen work needs to come from Apple
>
itself.
I'm not proposing any change to how osaxen work. They install their event
handlers in a system table, and when the event occurs, the osax gets sent the
event.
>
I'm aware this is raining on folks' parade somewhat. But, seriously, say
>
you take a look at the current community support for - and use of -
>
AS-based mods/libraries by way of comparison.
My proposal was not meant to solve the problems of loading and using libraries
of code. It was merely ment to help address the problem of the global name
space that is shared by scripting additions. It is more an issue for writers of
scripting additions than for writers of AppleScripts.
>
"What support?" I hear you cry. Well, exactly. AS must have the poorest mod
>
support of any commonly-used scripting language. Why? Because the language
>
itself doesn't give it the first class support it needs to make it
>
successful. Examples:
>
>
1. The folks who do bother to use mods can't even decide which part of the
>
system they should be stored in. Scripts folder? Scripting Additions
>
folder? Where?
>
I wrote a scripting addition to make this search process a little easier, but
mostly because I load most modules at compile time. I do this because the
applications I've been developing are more concerned with speed and less about
memory use. In that case, a scripting addition is handy because it exists
before any part of the script is written, so I can put all my 'property module :
load script ...' at the beginning of the script, rather than starting with a
handler to do the searching.
>
2. There's no built-in mechanism for loading mods into user scripts at
>
runtime.
Well, I usually use 'load script', and I'm pretty happy with what it gives me.
I've also use a script application that returns objects, as a runtime object
constructor, but that's difficult to debug.
>
Sure, a determined scripter can roll their own mod-loading code, but this
>
is a non-trivial task (see 2), made even harder since there's no consensus
>
on where modules should be stored in the first place (see 1 again).
Its not trivial, but its a simple problem to solve and then reuse easily. Bill
Cheeseman has shown one solution that is suitable--other scripters use other
solutions. There may not be a consensus because there are many different things
people are trying to do, and many different scripting styles.
>
So a valuable tool, used heavily in any other language worth its salt, is
>
left languishing on the sidelines whilst AS scripters far and wide
>
individually reinvent the same old wheels over and over again.
I think the reason reusable modules aren't as common in AppleScript is because
the focus of AppleScript is on controlling applications, and the applications
provide the power. You don't need a big library of code to do things because
you have access to the applications that were designed to do the work.
>
And that's with completely standard code used in a completely normal
>
fashion. So what chance would some unofficial, non-Apple sanctioned
>
low-level hack cooked up by some bunch of scripters that most ASers
>
probably haven't even heard of stand of making it into the next edition of
>
AppleScript in a Nutshell? Sorry, but IMMHO it'd just be a recipe for
>
another shambles.
Again, what I've proposed is not a solution to loading script modules. It
wouldn't appear in AppleScript in a Nutshell. It would be used by a Scripting
Addition writer, and the user would have to follow simple instructions.
1. Put the 'Foobar Addition' in the Scripting Additions folder
2. Put the 'Foobar Terminology' anywhere you want.
3. To use the handlers in the scripting addition, write,
using terms from application "Foobar Terminology"
foobar
end using terms
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden