Re: hash arrays and other mysteries
Re: hash arrays and other mysteries
- Subject: Re: hash arrays and other mysteries
- From: has <email@hidden>
- Date: Fri, 19 Oct 2001 16:23:34 +0100
Arthur J Knapp wrote:
>
> (I don't know why "run script" takes so much longer to compile
>
> and run a string of code than Smile's "do script" does). Though seeing the
>
> speed difference I think I'll be sticking with Smile myself.
>
>
The explanation usually given by those "in the know" is that the
>
AppleScript compiler has to be invoked during run-time, (rather than
>
once at compile-time), in order for the "run script" command to do it's
>
thing. This is where the appearent speed issues associated with "run
>
script" come from.
I can understand that compiling a string as executable code takes a certain
amount of time, and that doing this during runtime has implications for the
"parent" script's speed. Except Smile's "do script" does the same thing,
but in a fraction of the time. I don't understand why. Maybe Smile has its
own built-in compiler that happens to be faster than Applescript's own? Or
some other reason?
>
It's a shame that you weren't around for postings by Richard 23, I think
>
the two of you would have an affinity for each other's code:
Yeah, I just found his coercionToString handler. Completely unorthodox and
very clever. I'll need to spend a little time to figure exactly how it
works (it looks an ingenious little trick) - hopefully I can learn a thing
or two from it.
Anyway, just as a bit of a thinking-out-loud ramble about where I'm going
with all this... (and feel free to skip this bit if you prefer;)
One of the things I'm trying to do is make a script server that can
dynamically load an arbitrary collection of handlers out of a folder of
scripts. The user should be able to access any of these handlers just by
accessing the server: either through a 'tell application' block, or by
reading a property into which the server compiles and stores the handlers.
Partly it's a desire to improve the modularity of my own stuff (which is
still semi-monolithic and not very nice to work on), and give me a nice
easily-accessible, 'no-assembly-required' source for general-purpose
handlers. Unfortunately, one of the problems of the modular modular
approach is that you can soon find yourself writing lots of lines like:
tell application "scriptserver" to foo() of bar
when all you really want to write is:
property parent : application "script server"
which you've only got to do once, and then, whenever you want foo(), all
you gotta use is:
foo()
I think Macscripter's AppleMods points in the right direction: i.e. break
everything right down to individual handlers. That way you'd have a folder
full of scripts, each containing a single handler. But who wants to write:
property [handler name] : [handler name] of (load script "Hard Disk:System
Folder:Scripts:ModFiles:[name of file]")
a few dozen times at the top of each of their scripts?
Hence I've suddenly developed a real interest in "run script" as a way of
concatenating and recompiling script/handler objects (something I first
tried to implement - without success - some months back, but I've learnt a
lot since then). The real trick, I suspect, will be getting the script
server to rewrite the contents of its own run handler, which should then
make the loaded handlers available directly as a property of application
"scriptserver". Don't suppose anyone has already tried this sort of thing
and I've just missed it thus far? (Constant reinventing of wheels is
exactly the sort of thing I'm trying to avoid here, after all.)
<whew!> Have I flipped? Or did I just wake up in Bizzaro Land this morning? ;)
And then I go and look at Python, with directories and sorts and regex and
import and so many other juicy apples all as standard, and I can feel a
moment of weakness coming on. But I shall continue to be strong and resist
that wicked old snake, though it may tempt me at times like these... ;)
Cheers,
has