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: Victor Yee <email@hidden>
- Date: Sun, 20 May 2001 00:15:32 -0400
On Sun, 20 May 2001 04:32:42 +0200, Sander Tekelenburg wrote,
>
property pVar1 : "hello Tekelenburg"
>
script object
>
to sayHi()
>
return pVar1
>
end sayHi
>
end script
>
tell object to sayHi()
>
- --> "hello Tekelenburg"
>
>
your script works. But I seem to be missing something (that's probably
>
obvious :)) here: how does this apply to loading a compiled script?
A loaded script becomes a script object to the loading script, not named unless assigned to a variable. However, there are some differences to script objects declared in the main script.
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).
Another difference is that loaded objects don't recognise globals unless you pre-declare that global within that loaded object.
Although confusing, it seems to me that it does follow the rules of object-oriented programming. However, I'm still very much the novice in these areas and can't say for sure. I do find that I'm beginning to see the benefits of this behaviour, as it encourages me to stucture my scripting in a more maintainable fashion.
>
>>I thought the loaded script would 'see' the
>
>> Parent's globals
>
> absolutely not. that would be a disaster. think about what happens if an
>
> object reuses the name of a var in your script without your knowing ...
>
>
How would a variable name ever be used without my knowing? I am the author. I
>
decide how to name my variables. I make it a point to never use the same name
>
for a variable within 1 script.
>
>
Am I missing a key issue?
I believe the issue is maintainability. Breaking the encapsulation of an object means that the scripter has to keep track of globals not only in the main script, but also within every loaded script object.
This could be a problem, for example, if another scripter had to maintain scripts authored by someone else, that scripter would have to become familiar with every variable name used in the loaded scripts before mainpulating globals.
The need to declare globals in the loaded script prevents inadvertent sharing of variables in the loading and loaded scripts.
>
>> apparently both the parent and the child must be 'manually'
>
>> informed of each other's globals. Why? And is there a more elegant way to
>
>> do this?
>
> the key here is to think "if I have to tell the object about this variable,
>
> maybe it should be a property of that object, and not of my script?"
>
>
Are you saying I should get rid of globals altogether?
Globals aren't "bad", but they do have disadvantages; it's up to you to determine the pros and cons of using them. Also, you have to determine why you're using a loaded script object. Sharing globals with the loaded script means that the loaded script becomes more difficult to re-use in other projects.
HTH
Victor