Re: Modifications and Variables
Re: Modifications and Variables
- Subject: Re: Modifications and Variables
- From: Paul Berkowitz <email@hidden>
- Date: Sat, 04 Jan 2003 15:17:13 -0800
On 1/4/03 11:26 AM, "Axel Luttgens" <email@hidden> wrote:
>
With above examples in mind, I may now briefly summarize my
>
understanding of the ASLG about those matters (especially pp. 303-304
>
and 311-316):
>
>
A variable declaration is the first valid occurence
>
of a variable identifier in a script.
>
Any variable declared at the top level of a script
>
is a global variable, unless explicitely declared
>
through a "local" statement.
>
The top level of a script must be understood as
>
including every statement that should appear in an
>
explicit run handler.
>
>
And I should add (a bit provokingly?) that an explicit run handler
>
appears to me more as a cosmetic matter than anything else; there is no
>
such handler, there are just top level statements.
The muddy area is the statement that all top-level variables are global. In
fact, they're not global unless they're explicitly declared global, either
at the top level itself, or in individual handlers as you've been doing.
They're "semi-globals": or "potential globals" they persist, like globals,
and the script can find them if you choose to declare them as global within
a handler: that's why I say "potential global". they do inhabit that
name-space, but unless you expressly declare them global, other handlers
don't acknowledge them and create new local variables with the same name.
they actually behave as if they were locals - just like undeclared variables
within handlers - until you find that they persist. Maybe it would be better
if top-level variables really were globals that needed to further
declaration?
>
>
> (What put me on to this is the fact
>
> that when you open a script in Script Debugger you can read all the values
>
> of every top-level variable from its last run.) How odd. What's it for?
>
>
>
I guess the idea was that if one declares a variable at the top level of
>
a script, it is because it must have a global meaning for the script;
>
otherwise, why should a variable be declared at the top level?
Just to use it, like any other variable. I'm not saying that the "global at
top level" isn't sensible, perhaps it is. But it behaves as a local, not a
global, unless you actually declare it global somewhere. Since that's how
local variables behave too, why not just make it local to the run handler by
default? Or - make them _real_ globals. One or the other. It's inconsistent
and deceptive the way it is now.
I guess much of the problem derives form the fact that you aren't forced to
declare variables explicitly in AppleScript - either as to scope or type.
Part of the "naturalness" of AppleScript, I guess. I actually declare all
handler locals in order to use Script Debugger's debugging, which requires
it. So all I need to do now is also declare top-level local variables too.
No big deal.
>
>
The real source of confusion resides in the possibility to write an
>
explicit run handler, which does not behave as regular handlers (for
>
scoping matters).
But that's all a "top-level" script is anyway. The real source of confusion
is that the top-level (or run handler) undeclared variables behave as
globals for persistence and for accessibility form other handlers (which can
declare them global for their own purposes), but don't have functional
global scope like declared globals. They're local to the run handler/top
level unless declared global.
>
>
>
>
> Does anyone know for certain if this sort of saving of new values at
>
the end
>
> of a script run is indeed something that would create an error if the
>
script
>
> was run by a user with execute but not write privileges? Naturally, I've
>
> declared all the variables as local in the meantime, but I'm interested to
>
> know if anyone has first-hand experience?
>
>
>
>
>
Good question.
>
I think remember that this could be the source of error messages.
>
I thus immediately tried, by saving this script as an application (Mac
>
0S 10.2.3):
>
>
-- Script4
>
try
>
set G to G + 100
>
on error
>
set G to 100
>
end try
>
on test()
>
global G
>
display dialog G
>
end test
>
test()
>
>
The file's authorization were thus:
>
>
-rwxr-xr-x luttgens staff
>
>
Running that application several times (by double clicking its icon)
>
displayed, as expected, 100, 200, 300... (and the modification date
>
changed too).
>
>
Changing the owner to root hindered the saving of the value of variable
>
G, so that each run showed, say, 400, 400, 400...
>
>
But no error messages were issued: the value of G was just silently not
>
saved.
That's good behavior. It's the same as Bill reported.
--
Paul Berkowitz
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.