Re: hash arrays and other mysteries
Re: hash arrays and other mysteries
- Subject: Re: hash arrays and other mysteries
- From: email@hidden (Michael Sullivan)
- Date: Fri, 19 Oct 2001 23:59:45 -0400
- Organization: Society for the Incurably Pompous
Greg Strange (Applescripter) writes:
>
I want an include statement in AppleScript. Plain and simple
>
that would make modular scripting a boon to the entire community. I also
>
want hash arrays but I digress. There is no reason why we can't load
>
handlers with a simple include/import statement just as you can with
>
Objective-C. Won't soemone just write the damn osax that does that? I
>
would gladly pay for it.
Now that's a great idea -- but is it really an osax question? What I
think we really want is the ability to link applemods (and hopefully
run-only byte code as well) in when creating an applescript app -- so
that we can distribute a single piece of code as a script, but are able
to maintain multiple files in the development process. Seems to me
that's got to be done in the editor, no?
>
We all agree on standards all the time. And we all disagree on standards
>
all the time. It's a question of meeting a need. Frankly, I would love to
>
have the access to hundreds of handlers and script libraries like I do in
>
Perl, Python and countless other scripting languages available on the Mac
>
these days. But it comes down to you and me, Paul, and all the other
>
scripters who want to move beyond writing their own (perhaps) inefficient
>
handler for the "entire contents of" bug. That's where we shoudl be pulling
>
together to increase AppleScript's value and robustness.
Now, along the lines of an include statement, would be the ability to
link to executable libraries from arbitrary languages. I can call mac
functions originally written in Pascal from a C program as long as I
have the function signature, why not the ability to do so from
Applescript? It's really quite easy to translate a function call into
applescript language (although there are lots of ways to do it).
This would make a lot of interesting libraries available right away, and
it also allows one to write language expansions without the speed
penalty of calling an osax. I try to stay away from osax calls in any
script that's going to be run by an active user because of that speed
penalty -- one reason I like applemods.
The ability to link extensions at compile time (sans appleevent
overhead) would make a huge difference for the more than casual
scripter. It also seems like a lot of gain for a little -- rather than
putting hash arrays and a whole bunch of other useful features into the
language -- they can be implemented as compile time extensions.
To be frank, unless something like this happens with Applescript, I'll
probably switch over to Perl or Python once I start working seriously on
OS X. Way too often I find myself running up against speed barriers
because something I need to do a lot in a script is only available in an
osax -- so I spend a lot of extra time implementing the function in solo
applescript. As applemods get's more full of good stuff, more and more
I find I can use a handler there, or at least cannibalize one for good
ideas that make writing my own a lot easier.
But if there were compile time extension linking available, it would be
much less of an issue.
What about the possibility of speeding up osax calls? Is that anything
like realistic? I notice it's faster to call applications than to call
osax, but it seems like the same activity in principle. Can something
be done about that? I wonder if it would be feasible to write something
that installed osaxen as FBAs and let their handlers be called as if
they were scripted programs in a tell block. Isnt' that essentially
what's happening behind the scenes when they are called from AS anyway?
Is it interpreter overhead because all that extra stuff isn't built
right into the byte code, so some recompiling of the script is necessary
everytime there is an osax call?
Michael