Re: References and subroutines
Re: References and subroutines
- Subject: Re: References and subroutines
- From: John W Baxter <email@hidden>
- Date: Wed, 4 Jul 2001 13:14:20 -0700
At 10:05 -0700 7/4/2001, Michelle Steiner wrote:
>
I discovered that this also fails inside a subroutine:
>
>
my ExecuteScript()
>
>
on ExecuteScript()
>
set theList to {5}
>
set theListRef to a reference to theList
>
contents of theListRef
>
end ExecuteScript
>
--> Can't make some data into the expected type.
>
>
The length of the list is immaterial.
>
>
Is this an applscript bug?
I see this part as a wise restriction, although it isn't necessary in that
routine.
Make a wee change:
global theList
my ExecuteScript()
on ExecuteScript()
global theList
set theList to {5}
set theListRef to a reference to theList
contents of theListRef
end ExecuteScript
and it runs fine. I think the fear is that someone will let that reference
sneak outside the handler...once the handler finishes if the variable was
local, it is gone and the reference points to stale memory. Rather than
analyzing whether that's going to happen (as it would if the handler ended
with return theListRef) it's just barred.
Now for the other case---the same adjustment makes the code work:
global theList
my ExecuteScript()
on ExecuteScript()
global theList
set theList to {}
set theListRef to a reference to theList
set theNum to 7
copy theNum to the end of theListRef
end ExecuteScript
In either case, if you don't want the list to be global (or a property, or
encapsulated in a script object as below) you'll need to do something other
than use references.
script holder
property theList : {}
end script
my ExecuteScript()
on ExecuteScript()
set theListRef to a reference to holder's theList
set theNum to 7
copy theNum to the end of theListRef
end ExecuteScript
holder's theList
--> { 7 } (on first execution, but as written holder's theList is
persistent)
--John
--
John Baxter email@hidden Port Ludlow, WA, USA