Re: facespan and reference usage/errors
Re: facespan and reference usage/errors
- Subject: Re: facespan and reference usage/errors
- From: email@hidden
- Date: Tue, 14 Aug 2001 21:37:44 -0400
On Mon, 13 Aug 2001 23:09:07 -0500, Michael Miller <email@hidden> noted,
>
>unable to create/manage a reference within a called
>
>handler.
>
>on run
>
>
>
>set aLIST to {"a","b","c","d"}
>
>set aREF to a ref to aLIST
>
If you declare your variable global (and fix the syntax problems)
>
then it works. Just add:
>
>
global aLIST
>
I'm not sure why it messes up when you use the reference locally;
>
it's probably an AS bug. Of course, you shouldn't need to use the
>
reference locally, since you have the actual data right there.
Its not a bug, its more of an efficiency issue.
In most programming languages, the implementation stores local variables on the
stack. Execution flow enters the handler, the routine allocates some memory on
the stack. Exiting the routine, it pops the allocation off the stack and its
quickly done. No reference counting, no garbage collecting, and if the handler
is recursive, each occurrence gets its own unique instance of the variable,
which is very good for modularity and not writing incredibly hard to debug
errors.
But if the language allows construction of reference to a local variable, you
risk giving that variable a life that lasts beyond that of the handler call.
For example,
to foo()
set a to current date
return a reference to a
end foo
set d1ref to foo()
-- do some stuff
set d2ref to foo()
Now, do d1ref and d2ref refer to the same variable? Do they have the same date?
Does the storage referred to even exist anymore?
There are way around this, ranging from C's approach (cause a bug due to a stale
pointer, permitting buffer overflow attacks on web servers) to Java's
(everything is already a reference, the local variable stores a reference to the
object on the stack, the return value is another pointer to the same object; the
underlying object exists until all references to it are lost and the object is
garbage-collected.) AppleScript could probably implement the Java method, since
it uses references for many things and garbage collects. But AppleScript
references are a little more dynamic than just a pointer to an object. They can
include calculation/reevaluation of the target, for example 'word -1 of
sillyString' will change depending on what sillyString changes to:
set sillyString to words of "Where do you want to go today"
set s to a reference to item -1 of sillyString
set end of sillyString to "Judge Jackson"
contents of s
--> result: "Judge Jackson"
Change the reference to "middle item of sillyString" and you'll clearly see that
its dynamically recalculating what the reference points to. Or, change the
reference to "some item of sillyString" and you get a different word each time
you use "contents of s" (or something that implicitly does a 'contents of', like
'display dialog "Hello, " & s '
Personally, I don't think this should be a high-priority issue for the
AppleScript language designers. The real reason most people use references is
because of the efficiency, not because of any real good use. And that speed is
not inherent in the language. Its just an oddity of the implementation. (As I
recall one of the Chris's saying something to the effect that, its not that
references are fast, its that non-references are unexplainably slower.) If
non-reference accesses got faster, I'd give up any claim on being able to use
references to local variables.
I can think of two other, legitimate uses for references:
- poking into lists ('set the contents of s to 42')
- side effects for functions, or call by reference,
'sort(a reference to myArray)
But I'll note the use 1 doesn't require the reference to be a storable value,
and I'd try hard to achieve the intent of the second approach by using an object
instead. Instead of reaching into the array and sorting it, teach the array to
sort itself.)
--
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