Re: A reference to problem (solved)
Re: A reference to problem (solved)
- Subject: Re: A reference to problem (solved)
- From: email@hidden
- Date: Tue, 5 Jun 2001 16:45:12 -0400
On Tue, 5 Jun 2001 03:43:43 +0200, From: "Serge Belleudy-d'Espinose"
<email@hidden> noted,
>
At 13:29 -0400 4/06/01, Arthur J Knapp wrote:
>
>
> A value created by the "a reference to" syntax creates the reference as
>
>a pointer to a value from some sort of "top level" object, either an
>
>application or a script. <<script>> means literally your script file.
>
>
>
> Because of this, your "local" varaibles cannot have references made to
>
>them, because references only refer to variables/properties of applications,
>
>script objects, or to global/properties of the main script.
>
>
(snip)
>
>
>on YetAnotherIdea()
>
>
>
> script TempScript
>
> property tempList : {}
>
> end script
>
>
The second example is much better, it even gives me the chance to retrieve and
>
return list values, something that the first one didn't allow if we wanted to
>
free the memory after handler execution.
>
>
As I understand it, you're saying that my example didn't work, because I was
>
trying to set ref to a variable local to a handler, and AS doesn't allow this.
>
However, since AS allows refs to script properties, you're just turning the
list
>
into one of them, and voila. So, using script properties is more or less like
>
storing the list in a different memory zone, where it can be accessed
>
differently.
>
>
I was used to making script objects and handlers inside them, but not the
other
>
way around, handlers and script objects inside them. Interesting.
This approach is a very interesting insight to scope and longevity of script
objects. I didn't think a script object defined inside a handler would be
accessible outside the handler. And in fact, this doesn't work:
on foo()
script Q
property u : 42
end script
end foo
u of Q --> The variable Q is not defined.
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
foo()
--> u of <<script Q>>
But note, the script Q is not being identified by its name. It carries the name
as a property, but what is being referred to is the script itself. For example,
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}
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.
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.)
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden