Re: Global variables
Re: Global variables
- Subject: Re: Global variables
- From: deivy petrescu <email@hidden>
- Date: Sat, 10 Mar 2007 13:52:18 -0500
Further, if you do not declare a variable in the top level of the
script as a global and run the script as a droplet, then the top
level variable does not become a global because the top level is
not run. But a global declared in the top level is global to the
droplet.
'Tis an interesting thread. I keep hoping I'll learn something from
it.
So do I. And I can say I did learn something.
It has always bothered me that globals, and I think properties too,
somehow become global to a world far outside of the script being run.
Well, that is what I hoped, but in many ways, see Axel's posting it
is not true.
In a truly compiled piece of software globals are "declared" at
compile time and they acquire assigned addresses in memory. But
AppleScript is a scripting language so it does matter if the code
that declares a global does or does not get "run". But then making
a droplet is called "save as application" and it is not at all
clear just what that means, especially if you are accustomed to
"real" compilers and linkers.
It does bother me that property values are supposed to stick
between successive runs of an AppleScript.
Actually, and this is important, *all* variables "stick" between
successive runs. The difference is that since the way one create it
is by setting it to something, it loses its last value on the first
"rerun".
But it is important to know that if you so something like
<example>
set LL to read thisHugeFileThatHas30MBworthOfText
</example>
LL will retain its value after you run the script. I found this out
the hard way. A script of mine got corrupted exactly because of a
line like that.
No special reading of a preferences file is required. But if you
recompile the values get changed - why?
If you recompile you are basically resetting everything. As for the
variable it is saved on the binaries of the file.
You want to see the variable?
Try the following example
<script>
set l to "It is a beautifull day"
set P to 5
set z to l & space & P & space
</script>
Save the script as script and open it with text edit. You will be
able to read every text. You will *not* see the first 5, that is P,
but you will see the 5 in z.
I believe that the "application" is actually re-saved to disk every
time it is run and that seems tacky when file system times and
dates are important.
I do not think so, I have some applications that use properties and
they are not reset after each run.
I could get used to that but when you toss in globals and discover
that they too do the same kind of thing I get terribly confused.
Running uncompiled scripts in Script Editor seems to come up with
common global memory for everything you do. Using the same name for
a global in two different scripts seems to cause problems for me
because of namespace confusion.
I've never tried that with Script Editor, in Smile you would probably
just override the first, but the beauty of Smile is that a variable
is *always* very very global.
Axel, a lot of good examples, the global ones did not bother me, but
the property did. I've always declared properties (and globals, if I
had to) at the beginning of the script. So I really never checked for
any anomalies.
I tried Ed's script, the one sent first, in another machine and it
run. Thanks Yvan and Malcolm for confirming this.
That, I did not expect!
I tried changing the line where the global declaration was and I'd
get an error. Which, for me made even less sense. That is move the
first line to any point after you've set the variable but before the
calls. It does not work.
So I thought it was the first line that had the magic. And *bingo*.
It is the first line...
Try commenting the first line something like
<example>
-- this line is a comment
global topLevelDeclaredGlobal
....
</example>
The script will not run!
If other have the same behavior ( I learn I have to be careful) then
I believe the compiler scans for property and globals in the very
first line. If there is something there, it probably scans the file
until the next line is not a property or a global.
Well, not exactly true. If properties are declared, then it does not
need to search for a variable to set it aside, this is done in the
property declaration. But in Ed's example, the global is declared in
the first line and set in the second. So the compiler probably
searches for its value since it already allocated the memory place.
I believe this is done because one does not need to declare what kind
o variable one is using (integer, string, list, etc).
I have not tried declaring a property in the second or any later
lines. I'll try that. I'll also try to run Ed's script but putting
the variable declaration way after the top line global declaration.
Ed says:
Whenever I use globals or properties I ALWAYS declare them in the
first lines of the top level handler, before any comments or script
and if I expect a variable to be global I ALWAYS delare it, when
used that way, globals are bulletproof.
IMHO, that is the most valuable lesson from this thread, that plus
this:
I think you proved this is true. To be bullet proof globals have to
be declared at the top.
If it is not a droplet, one will survive, but a droplet is a killer.
Please let me know if putting a comment does change the result for you.
I'll post my other results.
And whatever happens to handler also happens to scripts in the main
script body.
Deivy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden