records, a reference to, and the top level scope!
records, a reference to, and the top level scope!
- Subject: records, a reference to, and the top level scope!
- From: Richard 23 <email@hidden>
- Date: Tue, 2 Jan 2001 16:20:35 -0800
Paul Berkowitz quoted the following:
>
> Note that to set the referenced record it must be a top-level property or
>
> global otherwise it will not be visible to the ResetRecord handler.
then asked the following:
>
Richard,
>
>
Can you please review in that case why you are using "reference to" and
>
"contents of"? Is it meant to be a speed issue only in large repetitive
>
tasks? I tried your script both with and without the reference business and
>
it worked the same, given your proviso above. Do you always use "reference
>
to"?
I suppose I was being explicit (hope I didn't offend anyone).
It isn't really necessary but perhaps adds clarity. Actually the
reference to is a little misleading since the property is modified only
because the property is visible to the entire script. If you tried
ClearRecord on a variable which wasn't a script property and wasn't
declared global (and is therefore local to the containing scope) it
wouldn't work...unless of course the variable was defined in the run,
open handlers (or at the top level which is implicitly the run handler).
Records, lists and script objects are passed to a handler by reference
by default. If you want to be sure that a handler does not modify the
original item when passing such a value, "theList as item" or "contents
of theList" can be passed to a handler instead which results in a copy
being passed to the handler.
This modification does not occur when calling a handler in a running
applet from another script or from script editor however, so don't count
on the side effect where the handler's home will be in such a place.
-- ----------------------------------------------------------------------
-- Note1: I added the braces for the results, log doesn't do wysiwyg.
-- Note2: testList is defined in a handler (not implicitly or explicitly
-- in the run handler where the global nature of variables can
-- sometimes skew the results.
-- ----------------------------------------------------------------------
TestMe()
on TestMe()
-- CASE 1: original modified
set testList to {1, 2, 3}
TestMe2(testList)
log {result, testList}
--> {{1, "too", 3}, {1, "too", 3}}
-- CASES 2 and 3: original not modified due to items of/contents of
set testList to {4, 5, 6}
TestMe2(testList's items)
log {result, testList}
--> {{4, "too", 6}, {4, 5, 6}}
TestMe2(testList's contents)
log {result, testList}
--> {{4, "too", 6}, {4, 5, 6}}
end TestMe
on TestMe2(theList)
set theList's second item to "too"
return theList
end TestMe2
-- ----------------------------------------------------------------------
One more example to bring it on home:
Modifying the original slightly (applescript-users digest, Vol 2 #175 in
case you missed it) can demonstrate why I no longer test ideas in the top
level and instead always encapsulate scratchpad script ideas in a TestMe
handler. I've been burned before by the global nature of the top-level:
a script which works great until it's put into the a real-world (handler)
context where it fails miserably.
Commenting out the property declaration and lumping TestMe into the run
handler would work fine and would resemble the following:
-- ----------------------------------------------------------------------
--property Current_Record : {}
on run
-- TestMe()
-- end run
-- on TestMe()
set Current_Record to NewRecord()
set theRec to Current_Record
set {theRec's Findings, theRec's Impression} to {"deceased", "bugger"}
ResetRecord(a reference to Current_Record)
Current_Record
end TestMe
-- ----------------------------------------------------------------------
But when you uncomment all but the property declaration you get an error.
Even with "a reference to" it doesn't work. It seems to me there's
something a little fishy about that. The value can't have been garbage
collected as the scope it resides in hasn't been exited. I don't think
a reference to gets one in the conventional understanding, ie, a memory
location. Instead it seems to get a textual one: "Current_Record of
<<script>>".
Hope I've sufficiently muddied the waters! 8)
R23