Re: copy & set statments
Re: copy & set statments
- Subject: Re: copy & set statments
- From: Nigel Garvey <email@hidden>
- Date: Sun, 21 Oct 2001 15:54:21 +0100
David wrote on Sat, 20 Oct 2001 22:50:53 -0500:
>
set n to 2
>
set s to 5
>
set j to n
>
set n to 9
>
>
My question relates to the behavior of J. In the script above J is the
>
value
>
of what n was before N was changed. However, in the script below the
>
behavior
>
is much different. The behavior of the script below is different because
>
the
>
variable theList is changed even though it is not directly changed by the
>
script. Why does nAList act like it is the variable theList even though
>
theList
>
is not being used in that example?
[script snipped]
Variables compile as pointers, which tell the processor how to find where
the 'values' are stored in the computer's memory. These values exist
either as a result of some action by the script or because they've been
compiled into it.
When you 'set' one variable to another, as in 'set j to n' or 'set
theList to newList', the variable being set becomes the same as the
existing one - that is, it becomes another pointer to the memory location
where the existing value is stored. It points to the *same object*.
This isn't important with a simple value as you can't do anything to it
internally. You can only change the variables to point somewhere else, or
do something with the value that produces a result somewhere else. The
value itself is unaffected and can still be accessed through whichever
variable is still pointing at it.
However, with lists and records, it's possible to alter them *internally*
by changing their internal pointers to point to other values. If two
variables point to the same list, whatever happens *inside* the list
through the offices of one variable is visible when the list's accessed
through the other. (This is called "data sharing".) Either variable can
be reset to point to a *different* value without affecting the other, but
anything that happens inside a structure to which they both point is
visible to both.
The (AppleScript language) 'copy' command works in a slightly different
way from 'set'. It *duplicates* the existing value or structure in memory
and sets the new variable to point to the duplicate instead. With simple
values, it's immaterial which command is used (except that 'copy' takes
slightly longer and uses a handful of bytes more). But with lists and
records, the duplicate provided by 'copy' can be altered internally
without affecting the original.
This is something to remember when passing a list or a record as a
parameter to a handler. The local variable inside the handler is a local
copy of the pointer to the original structure, not a local copy of the
structure itself. If you want to fool around with the structure's innards
and still have the original intact when the handler returns, use the
'copy' comand first:
on myHandler(myList)
-- Reassign the variable to a local copy of the list
copy myList to myList
-- etc.
end myHandler
NG