Re: Inheritance dilemma
Re: Inheritance dilemma
- Subject: Re: Inheritance dilemma
- From: matt neuburg <email@hidden>
- Date: Wed, 23 Apr 2003 08:30:24 -0700
On Mon, 21 Apr 2003 14:43:32 -0700, David Graham <email@hidden>
said:
>
On Monday, April 21, 2003, at 10:17 AM, Paul Berkowitz wrote:
>
>
> Your handler was implicitly declaring a new variable foo with local
>
> scope,
>
> which is the default in handlers when no global is explicitly
>
> declared. It
>
> is a bit odd that that doesn't take over foo as its own property.
>
>
It sure looks like that's what's happening, I can't understand why it's
>
treating the parent's properties as a variables?!?!?
A property *is* a variable. There are some slightly special scoping rules
that apply to it, though; they don't seem relevant to what you're asking
here so I won't talk about them.
>
scenario that I first posted, I can't seem to set the parent's
>
properties. Changes to any of the parent's properties are treated as
>
local variables and are not persistent.
Okay, topic is now "persistence of properties." First of all, properties
are not special in this regard; all top-level objects persist between runs
of a script. (Please do not imagine I figured this out for myself: Mark
Alldritt had to hit me over the head with a two-by-four before I got it.)
That is a magical AppleScript feature. But now let's talk about what
happens after you save and close a script. Now persistence is not
guaranteed. It isn't a magical AppleScript feature; it's a feature of the
environment, as it were. For example, the current version of Script Editor
(the beta) resets properties. I think it does this when it opens the file.
It shouldn't do that (i.e. it's a bug, and a very different behavior from
the the previous version, 1.9) but it shows you what the problem is. As I
understand it, when a property changes, the environment might or might not
save the script as changed and it might or might not retain that next time
it opens the script. So:
property x : 1
display dialog x
set x to 2
Alter the script (to reset x), run, save, and close with the new beta
Script Editor. Open it again and run it; dialog says "1". Bad! Do all
those same things with the previous Script Editor (1.9); dialog says "2".
Good! This shows one aspect of the problem. But there's more to it than
that, because the question remains whether, in *any* particular context, a
change in a property will somehow get saved back into the script on disk
when you're done with it. As I say, AppleScript itself does not magically
guarantee this; it isn't responsible for files on disk, it just compiles
and runs stuff when told to.
>
set foo to load script alias "Dave's HD:Users:dgraham:Desktop:foo"
>
script bar
>
property parent: foo
>
end script
>
>
--> Can't compile -- error: "The variable foo is not defined."
>
And if you define "foo" in the same script, it does work ...
>
>
script foo
>
property fooBar : "blah"
>
end script
>
>
script bar
>
property parent : foo
>
end script
>
>
get fooBar of bar
Okay, topic is now scoping again. You are just confusing yourself with all
this talk about properties and load script, so just think about scoping.
Consider this code:
--global foo
set foo to 1
script bar
--global foo
display dialog foo
end script
tell bar to run
This errors at runtime unless you uncomment *either* commented line.
Unmarked variables are implicit locals; you need to say "global" to get
things to see each other outside their scope.
In the context of a script, an alternative is to leap explicitly to the
higher level. This is why scripts are cool (one of the reasons). So
instead of uncommenting either of those lines, this works:
set foo to 1
script bar
display dialog parent's foo
end script
tell bar to run
We've just been talking about a variable, an implicitly defined variable.
It is LOCAL by default. Okay? But then you change the subject and start
talking about scripts. That is a different matter. A script is defined at
the top level (of its scope) AS A GLOBAL. So, once again, let's make a
simpler version of your second example and not confuse ourselves with
parents and things like that:
script foo
end script
script bar
display dialog class of foo
end script
tell bar to run
bar can see foo because foo is global.
We can easily make an example that combines the two points:
script foo
end script
set fee to foo
script bar
display dialog class of fee -- blap, thank you for playing
end script
tell bar to run
That's the kind of thing you were trying to do. m.
matt neuburg, phd = email@hidden,
http://www.tidbits.com/matt
pantes anthropoi tou eidenai oregontai phusei
Subscribe to TidBITS! It's free and smart.
http://www.tidbits.com/
_______________________________________________
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.