AppleScript_ The Definitive Guide - Matt Neuburg [72]
set thePath to (path to me as string) & "Contents:Resources:myPrefs.scpt"
Unfortunately, a script runner environment that doesn't implement persistence might not know about script bundles either. Perhaps a better place might be the user's Preferences folder:
set thePath to (path to preferences as string) & "myPrefs.scpt"
If you open the file myPrefs.scpt in a script editor application, you may be surprised to find that it doesn't actually seem to contain your favorite color:
property favoriteColor : ""
Don't worry! The decompiled version of the script, which is what you're seeing, shows the original bytecode, not the persistent data stored internally with the script. But the persistent data is there. (The only way I know of to get a look at the persistent data stored internally with a script is to use Script Debugger. Script Editor doesn't show it, and destroys it if you open and run the script directly.)
Library
A compiled script file may be used to hold commonly needed routines. A running script can access the contents of the script file using load script. The script file's top-level entities, including its run handler, are then available to the running script that loads it. A compiled script file used in this way is called a library .
For example, AppleScript has no native command to remove one item from a list (that is, to return a list without its nth item). Let's write one. Ooooh, we've already done it; see "LISP-likeness" in Chapter 4. Save that script (the AppleScript version, not the LISP version); for now, let's save it as library.scpt on the desktop. Here's how to use the library:
-- load the library...
set f to (path to desktop as string) & "library.scpt"
set lib to load script alias f
-- . . . and use it
set L to {"Mannie", "Moe", "Jack"}
set L2 to lib's remvix(2, L)
L2 -- {"Mannie", "Jack"}
What are the advantages and disadvantages of using a library ? An obvious advantage is that it makes code reusable and maintainable. Here, remvix is a useful handler. We don't want to have to keep copying and pasting it into different scripts. If its code lives in a library, it becomes accessible to any script we write. Furthermore, if we improve remvix in its library file, those improvements are accessible to any script; a script that already calls remvix by way of load script acquires any new improvements the next time it runs. Finally, a library may consist of many interrelated handlers that call each other (and may even share values by way of top-level properties). When you load the library, you load that entire functionality and the handlers work properly without your having to worry about the complexities of dependency.
A disadvantage is that a library reduces portability. We cannot just copy a script that calls remvix to another machine, or send it to a friend, because it depends on another file, library.scpt, and refers to it by a pathname that won't work on any other machine.
With Script Debugger, a trick for working around this problem is to load any library files as part of your script property initialization:
-- load the library...
property f : (path to desktop as string) & "library.scpt"
property lib : load script alias f
-- . . . and use it
set L to {"Mannie", "Moe", "Jack"}
set L2 to lib's remvix(2, L)
L2 -- {"Mannie", "Jack"}
This works because, as explained earlier in this chapter, Script Debugger saves top-level entities into the compiled script file. So when you run this script and then save it as a compiled script file with Script Debugger, the property lib is saved in its initialized state, meaning that it contains the script object loaded from disk. The resulting compiled script file thus contains the library that it uses, and will run correctly in a script runner on another machine. In fact, this compiled script file can even be opened and executed using Script