Re: Script Libraries
Re: Script Libraries
- Subject: Re: Script Libraries
- From: has <email@hidden>
- Date: Tue, 9 Nov 2004 21:52:43 +0000
Simon Forster wrote:
Stuck. I'm assigning the script libraries to globals as in:
set libString to load script alias...
Arguably, comparable to include directives in other languages.
Which ones? C's include sticks all exported globals and procedures
into a single namespace. (You have to fake namespaces by adding
unique prefixes to each identifier, and hope nobody else is using the
same one. Not a very intelligent way to operate, but that's C for
you.) Python's import sticks the imported module/its exportable
attributes into the current module's namespace. It doesn't pollute
the interpreter's global namespace, which is what you're doing.
You've got namespaces, make the most of them. This is why I say only
use locals and properties: they are namespace-friendly. Globals
aren't: to avoid collisions, each module must know which globals are
being used by every other module, which is not modular programming.
As there is _some_ coupling (<--new word usage from Simon!!) between
functions, the coupled functions reference the global variables
containing the script libraries. The only alternative is to pass the
library(s) as arguments to each of the functions.
No, you can put libraries into properties in the script that uses
them and reference them there. This is what the AppleMods libraries
do; they've already solved these problems. Trust me, I've been
through all this stuff myself, including the same (mis)use of globals
in my earliest attempts at modular design.
What mechanism do you propose (barring the use of a third party app
such as Loader written by someone nearby), to reference libraries of
routines?
The Loader system makes use of an applet when binding the Loader
library (actually, a proxy to it) to scripts at compilation time:
property _Loader : run application "LoaderServer"
This is simply for developer convenience: it saves them having to use:
property _Loader : load script (alias "Some Path:That's:Not Very:Portable")
The applet isn't used when the script is run, however.
The Loader system is an obvious choice for AppleScript module
management and binding: it already solves these problems about as
well as can be expected without access to the AppleScript language's
internals. It has the potential to become the standard if enough folk
start using it, and as the only serious solution in town there's not
a whole lot of alternatives to choose from: Apple don't seem in any
hurry to fill this hole themselves and there's no other third-party
equivalents available. It's also covered by one of the most liberal
licences available, so even if AM were to disappear tomorrow, Loader
would continue to be completely open and freely available. You could
implement your own system, but why spend time and energy reinventing
a wheel that already exists?
[For some reason, AppleScripters have a big problem with code reuse,
even more when its not their own; in other languages it's absolutely
standard practice. This is why AppleScript largely remains on the
bottom rung year after year while its peers and even juniors fly past
it: with many time and hands contributing to the common good, the
wheels are soon finished and they can get on with the Ferrari.
Meanwhile, every newcomer to AppleScript has to chop their own tree
and build their own lathe before they can get on with any kind of
serious work, which is absolutely mad.]
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