Re: hash arrays and other mysteries
Re: hash arrays and other mysteries
- Subject: Re: hash arrays and other mysteries
- From: Paul Skinner <email@hidden>
- Date: Fri, 19 Oct 2001 14:19:27 -0400
SNIP.
>
>
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()
>
Right. So there's your answer. Apparently you don't want this solution? Or
are you saying that you are having no luck implementing this? I do just that
and it works like buttah.
--begin script
property parent : application "AppleScriptServer"
tid("")
-->""
display dialog "Enter your name." default answer "Paul Skinner"
-->{text returned:"Paul Skinner", button returned:"OK"}
asciisort(every character of the text returned of the result) as text
-->" aeiklnnPrSu"
swapCase(the result)
-->" AEIKLNNpRsU"
writedata({the
Data:the result})
-->"OSX:Desktop Folder:011019135803"
--Which is a file containing "AEIKLNNpRsU".
--Note the date and time are used for the name of the file.
--This is the writedata() handler calling the dateandtime() handler.
--Sharing is good!
--end script
Or if you like tight...
--begin script
property parent : application "AppleScriptServer"
display dialog "Enter your name." default answer "Paul Skinner"
writedata({the
Data:swapCase(asciisort(every character of the text returned
of the result) as text)})
--end script
>
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]")
>
Not me.
>
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.)
>
That sounds like a variation on the first
parent-property-direct-handler-call method that you mentioned, just more
complex.
Why do you want to modify the handler server dynamically? What is it
that you're trying to do? Keep the handlers in the handler server synced
with the actual scripts? I do this by making the quit handler in
AppleScriptServer ask me if I want to quit or quit and restart. The run
handler initializes the properties so that they're all up to date.
>
>
<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
Don't give in! I have found the Perl mods to be my greatest temptation.
But I don't like writing Perl. I just decided to make my own mods for
AppleScript. maybe I'll let em run free once I feel they're ready. Maybe on
Applemods
Applemods does have a great concept in creating a space for this type of
effort. I think that the freeform nature of most scripter's coding and lack
of any call-return standard is going to limit it's usefulness though.
If you have to open the handler and read it to understand what it wants
and what it will give you back, then it won't grow properly. I don't know
about what others do, but when I get a handler from someone, I open it,
'fix' the variables to my style, read through the code trying to compile it
in my head; and the take the whole thing apart and rebuild it. Now I can't
take that new code and feed it back into the system. All of the scripts that
anyone has written that call that handler will break if they DL my new and
improved version. Re-coding every script that uses asciiSort() because
someone's new faster code wants different input or returns a record instead
of a list ain't gonna happen.
Now if there was a way to get everyone to agree on 'standard' input and
output for handlers, we might even get the idea of mods for AppleScript off
the ground.
BAHAHahahah! Well, I TRIED to say 'standard' with a straight face. We all
know that it isn't likely that everyone will use any standard even if some
people could agree on what that should be.
--
Paul Skinner