Re: Script objects 'as string' in an identifiable way
Re: Script objects 'as string' in an identifiable way
- Subject: Re: Script objects 'as string' in an identifiable way
- From: has <email@hidden>
- Date: Fri, 9 Nov 2001 16:08:32 +0000
Scott Norton didst respond most comprehensively:
>
On Thu, 8 Nov 2001 11:14:25 +0000, has <email@hidden> asked,
>
>
> >2. You can pass script objects between applications, but its pretty
>
>slow. I
>
> >have one script server which I call in a block that looks like this:
>
>
>
> Slower than calling handlers in a script server? Or is either method
>
> equally slow?
>
>
Fundamentally, asking a script server for a script object is an
>
interapplication
>
handler call, and so is slow. What I was doing was to ask for a script object
>
(which was one interapplication handler call), and then asked the script
>
object
>
to do a bunch of things (which were local handler calls). If I asked the
>
server
>
to do each of those things, each request would be an interapplication handler
>
call, and so slow.
Right... as in (pseudo-ish code):
tell application foo to set my LocalScriptObject to its ScriptObject
repeat 100 times
LocalScriptObject's bar()
end
(fast), versus:
repeat 100 times
tell application foo to bar()
end
(slow). And if you're only using the object once, you don't even need to
store it in a local variable (as in your example).
-------
>
In the particular situation I had, the script server had a bunch of
>
configuration information, which changed slowly, and was called by a bunch of
>
small scripts that were called by ListSTAR in response to different types of
>
e-mail and on different timers. Each small script would ask the script server
>
for an object that did the job needed, would do that job using the script
>
object. It was faster than loading the object from disk with a run time "load
>
script" statement, and easier to manage configuration that a compile-time
>
"load
>
script".
So if an object's going to be used frequently, best to use a script server
and get it from that then, yes?
>
It also allowed me to change the script server, and change the
>
underlying configuration of the system, without having to shut down and
>
restart
>
every other component, and without inconsistent data during a transition. The
>
script server acted as a gatekeeper and mediator, but without doing everything
>
itself. Essentially, the script server empowered the little scripts to do
>
their
>
jobs. The server didn't do the job, it just gave the little scripts the code
>
and the information needed to do the job. [snip rest of description]
It sounds pretty impressive bit of work.
---
OK, one of the things this has got me considering:
======================================================================
(*handler server*)
on foo(bar)
beep bar
end
(*local script*)
property foo : {}
on init()
tell application "server"
copy its foo to my foo
end tell
end init
init()
repeat 5 times
foo(1)
end repeat
======================================================================
Which would allow you to call these handlers from anywhere in the local
script, and as often as you liked, just as if they really were local. It'd
be just like using property parent, but without the persistence. Plus
you're only getting the stuff you need.
A really neat trick would be to get the init() handler into the server as
well, so you could load everything into your properties with just a single
line:
tell application "server" to init({foo, anotherHandler, andAPropertyToo})
but I ain't cracked it yet;). It'd be very nice if you could though,
because you could package it up as an easy-to-use server that even novices
could use without having to know about or deal with object hierarchies.
>
But actually, I didn't do things this way just for efficiency. I did it
>
so the
>
code would be easier to read, while not being too inefficient and not
>
being too
>
labor intensive to deploy.
I started doing modular design after writing 60KB+ code in a single script.
Reading and debugging that thing was getting pretty ghastly so after
struggling a bit I modularised it, but I won't claim the result was
terribly tidy (as you can imagine for such a remedial hack).
I'm sold on the modular approach; now I just gotta learn how to do it
correctly before I start on any more big stuff. Still having hassles with
inheritance and stuff; need to give the ASLG another read, I think. But
getting there, hopefully.:)
Many thanks for the great reply.
has