Re: copy & set statements
Re: copy & set statements
- Subject: Re: copy & set statements
- From: Nigel Garvey <email@hidden>
- Date: Wed, 24 Oct 2001 03:55:38 +0100
Timothy Bates wrote on Tue, 23 Oct 2001 23:42:46 +1000:
>
On 23/10/01 11:08 PM, "Nigel Garvey" <email@hidden>
>
wrote:
>
> on myHandler(myList)
>
> set item 1 of myList to "a" -- make a change within the list
>
> end myHandler
>
>
>
> set theCat to {"woody", "hungry"}
>
>
>
> myHandler(theCat)
>
> return theCat
>
>
>
> -->>{"a", "hungry"}
>
>
Demonstrating that, indeed, handler parameters ARE passed as pointers and
>
others as values. Geeze, that is a really bad inconsistency in the
>
language, and one of which I was unaware.
Passing a pointer is obviously more efficient than passing an entire copy
of a list - like giving someone your address rather than a duplicate of
your house. But I'm not sure that the inconsistency's in the
(AppleScript) language so much as in the metaphors we use for
convenience. We talk about passing a value to a handler because it's
usually unnecessary to talk about passing a copy of a pointer to a
pointer to a value. We talk about different variables and assume that the
values they "contain" are discrete too. When this leads to problems with
lists and records, we special-case them and call it "data sharing".
>
I guess the way around it is that _everything_ should be passed as a
>
pointer.
I'm guessing that this is what happens anyway. (Ah. I see Scott's just
confirmed this.) A couple of years ago, John Baxter corrected one of my
early assertions on the MACSCRPT list by describing how variables are
accessed in AppleScript:
>
AppleScript makes heavy use of the Macintosh memory entity known as a
>
handle. A handle is a pointer to a ("master") pointer which in turn points
>
to a block of memory. The latter block can be easily moved around,
>
resized, released back into the heap of available space, etc. It's only
>
necessary to adjust the "master" pointer appropriately.
I hope I haven't misunderstood this when I equate a handle with a
variable. Each points to a particular "master" pointer, which in turn
keeps track of where the variable's 'value' is stored at any particular
moment through the occasional OS memory tidy-ups. With this arrangement,
it's only *necessary* to pass a handle to a subroutine, whether the data
type of the value be integer or list. It's more efficient and (I imagine)
easier to implement than having the compiled code check each value before
deciding how to present it to a handler.
NG