Re: Scope of globals, parents and children, "load script" and all that jazz
Re: Scope of globals, parents and children, "load script" and all that jazz
- Subject: Re: Scope of globals, parents and children, "load script" and all that jazz
- From: Sander Tekelenburg <email@hidden>
- Date: Sun, 20 May 2001 16:00:35 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 00:15 -0400 UTC, on 20/05/2001, Victor Yee wrote:
>
On Sun, 20 May 2001 04:32:42 +0200, Sander Tekelenburg wrote,
[...]
>
A loaded script becomes a script object to the loading script, not
>
named unless assigned to a variable.
Yes, I see that now. The "load script" command not only loads a compiled
script. It also implicitly declares the loaded script to be an object.
[Reminds me of that old Desktop Database issue: double-click a file in the
Finder, and the Finder will open it for you in the appropriate application.
Nice, until it stops working and the user doesn't realise he can still launch
an app and tell it to open the file. User-friendlyness has its drawbacks :)]
>
However, there are some
>
differences to script objects declared in the main script.
I haven't declared anything within the main script as an object. Or is a
handler a script object even when you don't explicitly state it?
>
For one thing, a loaded script object doesn't seem to recognise its own
>
handlers (although it will recognise its own script objects). That
>
means that you can't have one handler in the loaded object call another
>
handler within that same loaded object unless they're both wrapped
>
within a script object declaration within that loaded object (whew, I
>
just confused myself).
I think I understand what you're saying, but it doesn't seem to be true. My
child script looks like this:
(* begin child *)
global gVar1, gVar2
on DoStuff()
if 1 + 1 = 2
DoMoreStuff()
end if
end DoStuff
on DoMoreStuff()
global, gVar1, gVar2
-- do some stuff with gVar1 and gVar2
endDoMoreStuff
(* end child *)
So the first handler (which doesn't contains any globals) calls the second
handler. No problem. Or are you saying that declaring all those variables as
globals everywhere turns the handlers into objects?
>
Another difference is that loaded objects don't recognise globals
>
unless you pre-declare that global within that loaded object.
When, at the top of the child, I declare some variables as globals, why do I
still need to declare (some of) them as globals _again_ within that same
child's handlers?
[...]
>
> >>I thought the loaded script would 'see' the
>
> >> Parent's globals
[...]
>
This could be a problem, for example, if another scripter had to
>
maintain scripts authored by someone else [...]
Ah. I hadn't thought of that. Yes, that sounds like a good reason not to have
globals be too global :)
>
The need to declare globals in the loaded script prevents inadvertent
>
sharing of variables in the loading and loaded scripts.
Yes. Understood.
[...]
>
Sharing globals with the loaded script means that the loaded script
>
becomes more difficult to re-use in other projects.
That's not an issue in this particluar case. But I see your point.
It is slowly beginning to make more sense. But it isn't clear to me yet :)
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <
http://www.pgp.com>
iQA/AwUBOwfOAOsywKfXgqKdEQJ4mwCgrVFe5NIWcfs/CCh2OQUMXIfxWOEAoI7E
Y/PxzdmDKytPbvQz/xT3fvwA
=B5pB
-----END PGP SIGNATURE-----
--
Sander Tekelenburg, <
http://www.euronet.nl/~tekelenb/>
Mac user: "Macs only have 40 viruses, tops!"
PC user: "SEE! Not even the virus writers support Macs!"