Re: A reference to problem (solved)
Re: A reference to problem (solved)
- Subject: Re: A reference to problem (solved)
- From: Arthur J Knapp <email@hidden>
- Date: Wed, 06 Jun 2001 10:26:57 -0400
>
Date: Tue, 5 Jun 2001 16:45:12 -0400
>
From: email@hidden
>
Subject: Re: A reference to problem (solved)
>
But you can get a reference to Q, and then work with it.
>
on foo()
>
script Q
>
property u : 42
>
end script
>
return a reference to u of Q
>
end foo
>
>
set u1 to foo()
>
set contents of u1 to 17
>
set u2 of foo()
>
{u1, u2, contents of u1, contents of u2}
>
--> {u of <<script Q>>, u of <<script Q>>, 17, 42}
Good stuff, Scott.
These leads us to a general handler for creating references within
handlers:
on NewRef(val)
script obj
property a_ref : val
end script
return a reference to a_ref of obj
end
on foo()
-- Need a reference:
set localVar to NewRef({})
>
Internally, I imagine that each instance of script Q is created in the heap
>
when
>
the "script Q" statement is executed inside foo(), and that script is bound to
>
the variable name Q inside foo(). Then, when "a reference to u of Q" is
>
created, what is produced as the reference is, "u of [[that thing]]" with
>
[[that
>
thing]] being the script's as it lives in the heap. Then, when the handler
>
foo() exits, and variable Q goes away, but the script Q on the heap lives on,
>
since it has this reference thing pointing to it.
I am not a programmer, but I am facinated by learning about the
"low-level" processes behind the language.
AppleScript uses "automatic garbage collect", which appearently means that
once a value is no longer being "pointed" to by any variable, that value's
"space" in memory is reclaimed. It is interesting that this should be true
not only of "true" variables, but also of "a reference to" variables,
despite the fact that the thing being referenced has no "true" variable
anymore.
>
When foo() is again entered, a new script object is created, pointed to by Q
>
and
>
pointed to by the reference "u of [[that new thing]]"
>
>
(Note that above, when I say, "the heap", I don't mean the Mac's System Heap
>
or
>
Application Heap, but just the block of randomly-allocated storage the
>
application uses, as opposed to "the stack", which is always allocated
>
last-in,
>
first-out. The stack is where local variables and function arguments live,
>
the
>
heap is where persistent values are kept.)
That's a heap of info that you've stacked up, Scott, thanks. :)
Arthur J. Knapp
http://www.stellarvisions.com
mailto:email@hidden
Hey, check out:
http://MacScripter.net