Re: Inheritance
Re: Inheritance
- Subject: Re: Inheritance
- From: Axel Luttgens <email@hidden>
- Date: Thu, 22 Jan 2004 14:36:32 +0100
[ === PART I === ]
Wallace, William wrote:
[...] I get the same kind of error as with my second example: "m
doesn't understand the doIt message."
Let's go back to your original example:
-- script 1
to doIt()
set my parent's z to 4
end doIt
-- script 2
to suggestIt()
tell my parent's m to doIt()
end suggestIt()
--main script
property z : 3
set m to (load script alias "path:to:script 1")
set p to (load script alias "path:to:script 2")
p's suggestIt()
When you asked some days ago "Shouldn't that work as well [...]?", I
answered "IMHO, it should set z to 4".
My answer was rather cautionary...
In fact, your code "works" but... only very partially because of
inheritance (this is the subtlety I announced yesterday).
But let's first try to understand the error message you got:
"m doesn't understand the doIt message"
At the view of that message, I yesterday guessed that you inadvertently
tried to run your main script from the Script Editor and not as an
standalone application.
The explanation resides in the ASLG's excerpt I reproduced the other day:
The current application is either the default target
application or whatever application is currently set
as a script's parent property. The default parent
property for any script that doesn't explicitly declare
one is the default target application -usually, the
application that is running the script, such as the
Script Editor.
OK; let's thus be explicit (and even minimalist, as an attempt to focus
on the essential).
Run this one in the Script Editor:
-- Example 1
script a
property parent : application "Script Editor"
on doThis()
tell my m to doThat()
end doThis
end script
a's doThis()
--> Error in Script Editor: m doesn't understand the doThat message.
We thus get a similar message, but also a better insight of its real
meaning.
In fact, the message tells us that a property named m couldn't be found...
And what about minimalism without explicity?
-- Example 2
script a
on doThis()
tell my m to doThat()
end doThis
end script
a's doThis()
--> m doesn't understand the doThat message.
We now get exactly the same message as the one issued when running your
"main script" in the Script Editor.
In fact, when run from the SE, your "main script" invokes "script 2"
which tries to find a property m (own or inherited) that doesn't exist.
And "script 1" isn't involved at all!
Could we be even more minimalist?
Yes, once we remember that the top-level script (hereafter TLS) in fact
is a script object:
-- Example 3
on doThis()
tell my m to doThat()
end doThis
doThis()
--> m doesn't understand the doThat message.
Or, with ultimate minimalism:
-- Example 4
tell my m to doThat()
--> m doesn't understand the doThat message.
Being a script object, any TLS, when run from SE, should implicitely
inherit from SE and have SE as target.
Let's check the theory once again:
-- Example 5 - when run in SE
-- Refer to a SE's property
my name
--> "Script Editor"
-- Invoke a SE's command
exists window 1
--> true
Now, save this one as an application and double-click on its icon:
-- Example 6 - when run as an applet
my name
--> Can't get name.
Right: the script now inherits from (is a children of) the applet
itself, which doesn't have a "name" property.
Let's now somewhat extend example 4:
-- Example 7 - in SE or as an app
property m: false
tell my m to doThat()
--> Can't get doThat of false
Quite logical: instead of trying to find an inherited property, the
script just uses its own one; and, obviously, false can't do very
much... [1]
A variant of the above:
-- Example 8 - in SE or as an app
tell my m to doThat()
--> Can't get doThat of false
property m: false
This shows that "property" statements aren't executable ones; they are
evaluated before a script's execution, so that the corresponding names
and associated values are known when the execution begins.
Well.
We may now start with the subtlety.
Let's slightly leave our minimalism and run this from SE:
-- Example 9
property m: false
script a
tell my m to doThat()
end
tell a to run
--> Can't get doThat of false
So, "script a" has found and tried to use "m".
But... wait a moment...
Shouldn't "script a" inherit from the Script Editor? [2]
Would that mean that SE has a property named "m"?
Obviously not:
-- Example 10
property m: false
script a
property parent: application "Script Editor"
tell my m to doThat()
end
tell a to run
--> Error in Script Editor: m doesn't understand the doThat message.
So, we may be reassured: SE doesn't have a property named "m".
But Example 9 then shows that something else than inheritance is in the way.
That "something else" belongs to the dark side of AppleScript.
I mean AppleScript's scoping rules. [3]
[1] The phrasing of the error message is quite interesting by itself. It
tends to show that a script object's handler in fact is a property of
that script object.
[2] Even if "script a" is defined into the TLS and thus, in some sense
belongs to the TLS, this doesn't mean that "script a" is a children of
the TLS.
[3] Hello Paul, hello has ;-)
[ === GO TO PART II === ]
_______________________________________________
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.