Re: copy & set statements
Re: copy & set statements
- Subject: Re: copy & set statements
- From: Nigel Garvey <email@hidden>
- Date: Wed, 24 Oct 2001 03:55:40 +0100
Timothy Bates wrote on Wed, 24 Oct 2001 11:10:16 +1000:
>
This is getting weird:
>
>
set theCat to {"woody", "hungry"}
>
myHandler(theCat)
>
theCat --> {woody,hungry}
>
>
on myHandler(myList)
>
set myList to myList & "a" -- make a change within the list
>
end myHandler
This operation is a concatenation, which makes a new list consisting the
items of the original list and the item on the right of the ampersand.
(More properly, in this case, as the item on the left of the ampersand is
a list, the item on the right is coerced to list too, then a new,
combined list is created.) The variable myList is set to point to the
new list. The original list remains unchanged as is still pointed to by
theCat.
>
BUT
>
>
>
set theCat to {"woody", "hungry"}
>
myHandler(theCat)
>
theCat -->{"woody", "hungry", "a"}
>
>
on myHandler(myList)
>
set end of myList to "a" -- make a change within the list
>
end myHandler
Here, an item actually *is* added to the original list, so it shows when
you look at the list with the other variable that points to it.
>
So, this "feature" only bites when you don't cause AS to dereference (and
>
copy) the pointer to the passed in parameter, hence Nigel's admonition to
>
explicity copy it if you can't afford external effects, but not to rely on
>
the external effect (calling a global instead to insure this) because it
>
only happens if you don't accidentally cause AS to transparently coerce the
>
parameter.
Well no. It's not as simple as that. ;-)
Seriously, though. It's simple once the concepts are sorted out - and
it's only an issue with lists and records, and only when their contents
are changed.
By the way, pointers and references aren't the same thing.
NG