Re: copy & set statements
Re: copy & set statements
- Subject: Re: copy & set statements
- From: email@hidden
- Date: Tue, 23 Oct 2001 16:52:40 -0400
On Date: Tue, 23 Oct 2001 11:00:42 +1000, Timothy Bates <email@hidden>
asked,
>
To get the behaviour implied (where a handler deals with the original copy
>
of a list), you need to say
>
>
set theCat to {"woody", "hungry"}
>
>
myHandler()
>
>
theCat
>
>
on myHandler()
>
global theCat
>
set theCat to "a"
>
end myHandler
Unless you pass a reference to a function, AppleScript functions are pure
functions: they don't mess with their arguments. Its like C or Lisp or Algol
"call by value" semantics. But changing that behavior by going from a parameter
to a shared global is going back to Fortran and assembly language. You're
stepping backwards from the 1960's to the 1950's.
It would be better to use the functions as pure functions, and not using them
for their side effects:
set theCat to {"woody", "hungry"}
set theCat to myHandler(theCat)
theCat
--> result: "a"
on myHandler(something)
return "a"
end myHandler
Or, to take the most modern approach, bundle the data and its functions together
in an object. This example will look exceptionally stupid, because the example
I'm reimplementing doesn't show any information about what the data really is
and what methods really are. But it would have an outline like this:
script theCat
property catStuff: {"woody", "hungry"}
to myHandler()
set catStuff to "a"
end myHandler
end script
tell theCat to myHandler()
I wouldn't recommend the C-like approach of passing a reference into a function,
and fiddling with the contents of that reference, since pointers and addresses
are a significant source of bugs and confusion in C. Why use the most difficult
and easy-to-screw-up construct in the language?
--
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