Graham Jones wrote:
>Well, after hitting the Applescript Studio file size limit, I have been
>undertaking the task of splitting up my code into separate libraries and
>scripts.
>
>1st challenge: I would like to set a parent property in my libraries to
>refer back to the main script.
The parent property is read-only, so you can only assign its value when the script object is created (in this case, when your script is compiled).
However, binding the parent script to your libraries' parent property is the wrong way to tackle your problem for various reasons and won't actually solve it in any case. Instead, here's how to do it:
1. Put any properties containing shared state into a library of their own.
2. Bind each library to a property in your main script.
3. Have your main script pass to each library a reference to each of the other libraries it uses. The library should bind each of those references to a property in itself. Now when one library needs to refer to another, it just refers to the appropriate property.
Each script should refer only to things it contains, i.e. its own properties and handlers, and where a property contains a library, the script should refer to that library's top-level handlers only. (Note: while you can refer to a library's properties as well, it's better that you don't since such code will be harder to modify in future.) A script should never refer to things outside itself, nor to libraries that are nested within other libraries. Follow these rules and your problems will be solved.
Anyway, you can do all these library bindings at compile-time if you prefer; for self-contained applications it doesn't really make a difference if it's done at compile-time or run-time; static bindings are usually a bit simpler to do though.
If you want, you could use AppleMods Loader system <http://applemods.sourceforge.net> to handle all the library loading for you (it's great for this sort of thing and can handle even complex and deeply nested relationships with ease), though it's kinda short on documentation and examples (there's some documentation at <http://freespace.virgin.net/hamish.sanderson/LoaderDocs.sit> though it's a bore/chore to read; maybe if someone bugs me I might dummy up an example project or two). Or you can roll your own without too much difficulty if there's not too much stuff to juggle.
BTW, you can even pass libraries a reference to the main script if you really need to, though if you're doing that it's probably an indication of bad design. Circular dependencies are usually an indication of poor program structure, as is having large amounts of shared global state. Consider rethinking your program's structure to address this, as a program that's chock-full of complex interwoven dependencies will be difficult to develop, hard to debug well and a pain to maintain.
Also, a cautionary word: it's _much_ easier to construct an application in modular form when you design it to be modular from scratch than retro-engineer a large monolithic script into modular form. A good dependency graph should look more like a tree structure than a ball of yarn, and monolithic scripts tend to end up the latter. So expect to have to progressively rearrange and/or redesign various bits of code to eliminate knotty relationships before all the pieces will sit comfortably. I found out this the painful way the first time I tried to modularise a giant monolithic script for similar reasons. Taught me a lot about how _not_ to design big programs, that exercise did. :p Thereafter, I always designed and built big projects to be modular from scratch and have had no headaches since.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-studio mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/applescript-studio/email@hidden
This email sent to email@hidden
