Re: Scope of globals, parents and children, "load script" an
Re: Scope of globals, parents and children, "load script" an
- Subject: Re: Scope of globals, parents and children, "load script" an
- From: email@hidden
- Date: Mon, 21 May 2001 15:38:54 -0400
On Sat, 19 May 2001 15:05:43 +1000,
Timothy Bates <email@hidden> wrote,
>
On 5/18/01 4:52 PM, "email@hidden" <email@hidden> wrote:
>
> Any handler (which includes the implicit run handler of the main script)
that
>
> wants to use a global variable must declare it as such. The philosophy is
>
> that an outsider can't steal a handler's variables. That is, an outside
bunch
>
of
>
> code should not be able to change the meaning of code inside a handler by
>
> declaring a variable global.
[...]
>
Isn't that exactly what happens? For example in the code below, my global
>
"i" has been set to 0 and was accecssed implicitly by bar() without be
>
declared.
>
>
>
global i
>
set i to 100
OK, I'm wrong in the case of the implicit run handler. I was thinking of a
structure like this:
on foo()
set x to 5
bar()
baz()
return {baz: result, foo: x}
end
on bar()
global x
set x to 42
end
on baz()
global x
set x to x + 1
end
foo()
-- result: {baz:43, foo:5}
Here, the two handlers bar and baz share a global, but don't tell foo about it.
But if "global x" appears at the top level of the script before "foo" is
defined, in the implicit run handler (that is, not in an explicit "on run..."),
then foo "knows" x is global and shares in the fun.
The conceptual error I was laboring under was that the implicit run handler and
the script were the same. In fact, script level declarations are outside the
implicit run handler. I think the way it works is that if there is no run
handler, executable statements are gathered into the run handler, including any
variable declaration they cause (like "set x to 5"), but declarations (like
global x) don't get gathered in.
Script object declarations throw an odd twist into this mix, because a script
object can be executed (it returns itself), but don't migrate into the run
handler. So, compare these two scripts
set x to 5
script Q
property p1:0
end script
class of result
--> integer
on run
set x to 5
script Q
property p1:0
end script
class of result
--> script
end run
Apparently, the first script is the same as extracting the executable statements
(which doesn't include the script object) into separate run handler, as if it
were written this way:
script Q
property p1:0
end script
on run
set x to 5
class of result
--> script
end run
I try to just avoid these issues, by not using global variables and not using
the implicit run handler, if I'm doing something big enough that it merits
full-on software engineering.
And that reminds me to give the necessary propeller-beanie geek warning:
" The issues discussed here, regarding script objects, scope of variables, and
multiple handlers, are not usually relevant to most AppleScripters. AppleScript
is primarily about controlling applications, and the application, not the script
should define the objects. The application, not the script, should do the heavy
lifting."
--
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