Re: Compact Handlers Togo!
Re: Compact Handlers Togo!
- Subject: Re: Compact Handlers Togo!
- From: Paul Skinner <email@hidden>
- Date: Thu, 16 Aug 2001 00:26:54 -0400
on 8/15/01 1:53 PM, Bourque, Jason wrote:
>
Hello everyone,
>
>
I have been thinking that the handlers I create aren't that portable. i.e.
>
Copy the handler. Any properties or globals associated with the handler must
>
be copied to the top of the script
Properties must. As you show in your handler, globals can go anywhere.
>
So, I thought including the Properties and Globals in the actual handler
>
would make it much more portable.
I don't believe that properties can go in handlers in any way. I get
compilation errors if I try to fit them in there.
>
First to treat globals like properties and have the last value of global
>
keep after a run.
Right, I remember the discussion on the persistence of Globals. I found
this in the ASLG...
>
>from the ASLG
>
> Scope of Script Variables and Properties
>
> If you want the value of a script variable to persist after a script is run,
>
> or if you wish to use the same identifier in several different places in a
>
> script, you can declare it as either a script property or a global variable.
>
> AppleScript keeps track of properties and global variables across multiple
>
> handlers and script objects within a single script.
>
Below is the script that demonstrates what I have accomplished, but I am
>
looking for comments about it. i.e. If it is useful and am I understanding
>
the logic correctly, general comments.
Personally, I like putting my handlers into a script server.
A script server, for those who are wondering, is a script saved as a
stay open application. If there is an asciiSort() handler in the script
server then another script can use that handler by telling the script
server to asciiSort() just as you would tell any application to do
something.
--scriptserver application. Saved as stay open.
on beeper()
beep 3
end beeper
--Handlerless script.
tell application "scriptserver"
beeper()
-->beep,beep,beep
end tell
There are many ways to load handlers into your scripts, some WAY cooler
than this one, I won't get into them here.
I have a lot of handlers and if I had to put them each into every script
they'd be HUGE. I'm talking about disk space here and not the script's text
size ( AKA 32k limit in Script Editor. ). In short, when you use 'load
script' and compile, a copy of the handler you specified is stored within
the script. It doesn't count toward the 32K limit, but it is in the file. If
you modify the handler, you must reopen the script and recompile to get the
new handler functionality.
Some people like to load their libraries into their script. I like the
idea of having one instance of every handler that all of my scripts can
access. I also like being able to modify a handler and have the new version
be instantly used by all of my scripts. Of course, this requires care when
modifying them to avoid breaking dependant scripts. I feel like it a lot
easier to maintain. With a load script method you'd have to open every
script that contained a call to the modified handler and recompile them.
>
Please post all responses to the list, for I am in two locations with
>
different email.
Sounds like a portability problem. ; )
>
Thanks,
Snip! Script.
>
Jason Bourque
Remember that putting globals into your handlers lets the data inside
leak into your script body. Good and Bad. When you have 100 handlers, will
you remember the variable names in the first? Forget them at your own peril.
Alter them in another handler or in the body and your first handler may
misbehave.
But it does, as you point out, offer persistent values within the
handlers. I can see a lot of uses for that.
Personally I try to pass the handler data in the call and get data back
in the results without any other communication. If you are trying to build
portability into your handlers, it seems like internal globals could be a
weak point.
I use properties to provide persistent and 'globally available' values
to scripts and handlers, but I put them in the script server, they're
available to all of the scripts and handlers but they're all declared in one
script. This prevents me redeclaring them. The compiler won't allow a
property to be declared twice in one script.
--
"AppleScript is digital duct tape."
Paul Skinner