Re: AppleScript error, overflow.
Re: AppleScript error, overflow.
- Subject: Re: AppleScript error, overflow.
- From: has <email@hidden>
- Date: Fri, 8 Jul 2005 19:30:48 +0100
Hanaan Rosenthal wrote:
>Loader does seem cool and I will look into it.
>How is it different that normal loading of scripts?
It uses the standard 'load script' command to load libraries, so no difference there. The advantage is that it does all the tedious recursive dependency resolution work for you. For example:
- If you ask Loader to load library A, and A asks for B, Loader will also fetch B for A.
- If library C is required by both A and B, Loader will load D only once so that a single copy of D is shared between A and B.
- If library A requires B and B requires A (a circular dependency), Loader can resolve this too.
Other advantages:
- Loader is namespace-friendly. Namespaces are good. You don't really want great gobs of global state sprawling all over your program. 'Nuff said.
- Loader enables each script to manage its own dependencies for itself, and only for itself. None of that "One Script to Rule Them All, and In The Darkness Bind Them" nonsense. Low, loose coupling between a system's components is good. 'Nuff said.
- The Loader system allows individual libraries to have private dependencies (what it calls 'components') that are only available to it. These can be either compiled AppleScripts or Unix shell scripts.
- Loader can be used to bind libraries at either compile-time or run-time, according to when you call it.
- Loader can automatically load libraries from two standard locations, /Library/Scripts/ASLibraries and ~/Library/Scripts/ASLibraries. You can also supply your own search path if, say, you want to load libraries stored within your application's bundle.
Basically, Loader provides you with a robust, reasonably well refined library management framework so that you don't have to design and build your own one from scratch. As a bonus, c/o AppleMods you also get a nice stack of ready-to-use Loader-compatible libraries for free, most of which are also pretty good (by AppleScript standards, anyway).
>Also I was wondering, would I create a problem if I loaded ALL my subroutines into a single app and ran it as stay-open (as you suggested)?
Not entirely sure what you mean by that.
My suggestion was essentially to repackage some of your supporting libraries as stay-open applets (what some folks call 'script servers') to reduce the sheer number of objects any individual AppleScript component has to manage. This means that to perform some tasks, instead of calling handler in a library, you'd call it a separate program. That has some implications for speed, obviously. More importantly, it involves sending data via Apple events, which limits the types of values you can pass (application references are pretty much a no-no) and requires that any mutable values (lists, records, script objects, etc) are copied in the process. So you may be able to split off some functions where these restrictions aren't a problem, but other stuff will need to stay within the main program.
Not the most fun solution, in other words, and may not even be appropriate depending on your particular system, but if you can't solve the overload any other way (e.g. eliminating unnecessary duplication of code/loaded libraries) then it might be an option to consider.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden