Re: Running Subroutines from Other Scripts
Re: Running Subroutines from Other Scripts
- Subject: Re: Running Subroutines from Other Scripts
- From: has <email@hidden>
- Date: Sat, 24 Aug 2002 00:17:50 +0100
Adam Backstrom wrote:
>
I'm working on a series of AppleScripts written in AppleScript Studio.
>
For the sake of organization, I would like to split up the code into
>
several scripts.
AS doesn't really have first-class support for this sort of thing, so it's
basically a matter of rolling your own.
For a standalone ASS-based app, a simple static arrangement is probably best:
property moduleName : load script (alias "path to module")
...
tell moduleName to doSomething()
This will load your script modules at compile-time, thus avoiding the need
for your app to lug around a bunch of external script files. [1]
--
You may, on occasion, have a module that needs to be initialised upon
loading [2]. This can also be accommodated; eg:
--main script
property moduleName : init(baseState) of load script (alias "path to
module")
where the module contains an init() handler that takes the parameters
passed, uses them to set up the module's internal state, then returns
itself:
--MODULE
property _baseState : missing value
on init(theState)
set _baseState to theState
return me
end init
--rest of code here
--
In some situations a dynamic loading system would be more appropriate, and
various fancy [i.e. more complex] runtime loading systems can be arranged
to suit.
It'd be possible to write a whole essay on all the options open to you,
describing the pros/cons/reasons to use for each of them. But you probably
don't need anything fancy here, so go with what's simplest.
has
[1] BTW, I think the next version of ASS may allow multiple scripts in the
same app to communicate with one another, so perhaps in future you'll be
able to drop your module files into your project and let PB take care of
the rest. (After all, it's normal with C and friend to have source code
split across multiple files. And while the mechanics are a bit different
with AS, the overall point of the exercise would be much the same.)
[2] This can be particularly useful when you've got modules that use other
modules, and you want to keep things as flexible and loose as possible.
e.g. If an app uses modules A, B, C & D, and module A requires access to
the other three, I'll often pass those modules into A via an init() handler
for it to place into its internal properties for subsequent use.
You could have A statically load B/C/D for itself, but this can be a pain
for development as you'll end up also having to recompile A every time B, C
or D changes. It also means your application has just single instances of
B, C & D rather than two copies of B, C & D floating about (one lot in the
main app, the other lot in A), which means a smaller app and lower memory
requirements.
Or you could pass B, C & D via the handler calls you make to A. But who
wants their workaday handlers to look like: 'doSomething(theData, moduleB,
moduleC, moduleD)', with more parameters being used to pass modules than
data? In an ideal world, AS would have some sort of 'import' function where
all this sort of thing is handled for you, but for now we just gotta cross
our fingers and hope "next version maybe?" and get by as best we can.
--
(My email address has changed from <email@hidden> to
<email@hidden>. Please update your address books accordingly.)
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.