Re: "Save changes to script" when it terminates?
Re: "Save changes to script" when it terminates?
- Subject: Re: "Save changes to script" when it terminates?
- From: Michael Terry <email@hidden>
- Date: Mon, 15 Mar 2004 12:22:05 -0800
On Mar 15, 2004, at 4:00 AM, Walter Ian Kaye wrote:
I believe we all concluded quite a long time ago that a value
assigned to a
global variable does persist across invocations. I was an unbeliever
until a
script was posted that proved it. I haven't tried it in Mac OS X.
Did we determine if it was just when declared at the top level, or
also when declared in handlers without a top-level script? I don't
remember any words specifying it. We might have to test again, unless
someone remembers...
Global variables declared and initialized anywhere, anytime, throughout
the top level script's context become properties of the top level
script with all the rights and privileges thereof. They can be
initialized in nth level handlers or external files, at run time or
compile time. How and where they're declared affects matters of scope
and initialization, and the value a property holds affects how you can
access it (a property which contains a handler value can be called by
appending (), for instance). For purposes of being a property, though,
explicit top level properties, explicit top level globals, implicit top
level globals, explicit nth level globals, globals created through
second level evaluation tricks involving 'run script', globals
initialized in external files at compile time, and any others I've
missed share at least the following attributes, once initialized:
1. They each live until the end of the script.
2. They are persistent across executions of the script (so long as the
script runner is behaving).
3. Each can be queried for when its containing context is loaded by
another script.
4. While a script is running, the top level script object can respond
to requests for any of them.
5. Each is as good as another for fulfilling its role as a member of
the inheritance chain.
Here's an example of loading new handlers into the current top level
context by initializing a global in a separate file at compile time:
---------------------------------------------------------
-------------------------------------
-- library.scpt
-------------------------------------
on newHandler()
return 1
end newHandler
on run
global newHandler
set newHandler to my newHandler
end run
-------------------------------------
-- client.scpt
-------------------------------------
property load: run (load script (choose file))
newHandler()
--> 1
---------------------------------------------------------
In fact, what have been called "implicit globals" aren't really globals
at all--globality concerns scope. The scope of "implicit globals" is
confined to the run handler, the same as an explicitly declared local.
Here's an example showing that accessing an initialized, top level
variable is a matter of inheritance because it is a property, not
because of any type of global scope:
---------------------------------------------------------
script test
my x
end script
set x to 3
run test
--> 3
Now, subvert the usual inheritance chain, where script objects inherit
from the top level script:
script test
property parent : AppleScript
my x
end script
set x to 3
run test
--> error
---------------------------------------------------------
Here's an example showing new properties can be installed in any script
object. The key is to understand that initialized globals always bubble
all the way up to the top level as properties, so you've got to use
'run script' to give the script its own context to be the top level of.
You can't just tell the script to run, because that keeps it in the
current context:
---------------------------------------------------------
-------------------------------------
-- wrong way (for the example)
-------------------------------------
script test
property parent : AppleScript
global newProp
set newProp to missing value
me
end script
run test
newProp
--> missing value
Here, newProp, though initialized in the test script object, bubbled up
to the top level, not what we wanted.
Now, try this:
-------------------------------------
-- right way
-------------------------------------
script test
property parent : AppleScript
global newProp
set newProp to missing value
me
end script
set test to run script test
try
-- error because 'run script' loads a new version of
-- applescript component and runs the script object
-- inside it
newProp
on error
-- newProp is now a property of script object test
test's newProp
end try
---------------------------------------------------------
Mike
_______________________________________________
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.