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: Richard 23 <email@hidden>
- Date: Sun, 14 Mar 2004 14:08:05 -0800
>
There is great value in having a script be able to save state between
>
launches, the only problem is that it is automatic and pops up even
>
when you don't need it. I think that it would be better if you had to
>
save state explicitly, perhaps either by executing a "save state"
>
command or by having a special saved state variable. For example:
>
>
global theVar -- a global variable that does not save state
>
stored theVar -- a global variable that does save state
>
>
With this sort of variable we could avoid the whole mess of "is this
>
saved state or is it not?" I don't know if it is possible to easily
>
add this to AppleScript but it definitely would make things much
>
clearer.
>
>
-Ken
------------------------------------------------------------
DISCLAIMER: Although I guarantee that this post
contains a number of consecutive words, I cannot
promise reading them will bring absolute clarity.
------------------------------------------------------------
lets break things down a bit here.
** VARIABLES: SCOPE, DECLARATION AND ASSIGNMENT **
variables are a storage container for values which humans
refer to using a convenient label or variable name.
creating and storing values in variables requires
two discrete steps: declaration and assignment.
how these steps are accomplished varies from language to
language. some languages require both steps to be taken
explicitly, while others, like AppleScript, infer the
declaration when an assignment takes place.
many languages also provide a mechanism by which a script
can specify a variable's scope; ie, a section of code in
which a symbol can be used to refer to a variable by use
of its declared symbol.
a variable's scope may be either local or global.
a global variable may be accessed from anywhere within a
script, while access to a local variable is constrained
to the block of code in which it is declared.
in AppleScript a variable's declaration and scope
are defined in a single step.
Here are two explicit declarations:
global <variableName>
local <variableName>
In both cases, the variable is undefined until assigned
a value. In neither case does the an assigned value
persist across invocations: the variable is undefined
each time the script is run.
Assignment is performed using the "set" statement.
set <variableName> to <value>
AppleScript does not require explicit declarations.
It infers a local variable declaration where an
assignment occurs without an explicit declaration.
Unless a declaration occurs at the top-level of a
script (outside an explicit handler or child script),
the distinction between local and variable scope is
less clear, as both include the entire body of a
script.
** PROPERTIES (aka, persistant variables) **
AppleScript also provides scripts with a mechanism for
declaring variables whose values persist across invocations.
Unlike local and global variables which are assigned values
at runtime, the declaration and assignment takes place at
compile time and in a single step.
property <variableName>: <value>
Assignments to property values persist until a script is
recompiled, at which time the variable is again declared
and assigned the default value specified in the script.
------------------------------------------------------------
CAUTION: Sensitive scripters may wish to avert their
eyes from the following extra-curricular discussion
and move on to the next post....
------------------------------------------------------------
** the "undefined" value **
Propellorheads may note that the "undefined" value is
not the absence of a value, but rather a special value
type not normally referred to by scripts.
Indeed, when a script refers to the taboo value it is
magically whisked away during compilation.
Subsequent recompilation fails because AppleScript
doesn't allow scripts to get away with this kind of
devious behavior.
set theValue to <<class undf>>
theValue = <<class undf>>
is decompiled to
set noValue to
noValue =
which of course is nonsensical when recompiled.
Seasoned scripters may have come to assume that due
to AppleScript's syntax, script properties are never
undefined. R23 would respectfully dissent.
property No_Value: "undf" as type class
Logically this might lead to some kind of test for
undefined variables, but no dice. AppleScript cries
fowl when attempts are made to access variables which
contain the special "undefined" value.
Rather, scripts must tiptoe around "undefined" variables
either by explicit assignment or by containing risky
defined tests in try...error blocks.
Although nothing prevents a handler from returning
the undefined value, there are more straightforward
ways to do this if absolutely necessary.
on TestMe(returnResult)
if not returnResult then
"undf" as type class
else
true
end if
end TestMe
is better expressed as
on TestMe(returnResult)
if returnResult then true
end TestMe
if at all.
So other than confuse and scare those who should have
averted their eyes, what have I accomplished in this
fruitless exercise.
Gee, I duuno. Let me get back to you on that.
If you can't dazzle them with brilliance,
baffle them with ... something else.
R23
_______________________________________________
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.