Re: Inheritance and Loaded Libraries
Re: Inheritance and Loaded Libraries
- Subject: Re: Inheritance and Loaded Libraries
- From: Axel Luttgens <email@hidden>
- Date: Sun, 31 Oct 2004 12:08:13 +0100
David Weiss wrote:
[...]
Why do
my XLib's runTest()
runTest() of my XLib
both fail, but
tell my XLib to runTest()
works! This makes no sense to me. Any help would be greatly appreciated!
When I first read your post, I asked myself "why the hell does he want
to do things that way?". ;-)
In fact, it seemed you were using AppleScript's scoping rules to perform
some kind of "reverse pseudo-object programming".
Could you provide us with more details about what you wanted to do?
But you anyway raised an interesting point, so I played with the idea
while reading the ensuing thread.
Your initial question went about the interaction of following three
scripts (I just slightly modified ScriptRunner to ensure a systematic
initialization of property XLib; on the other hand, as Paul noticed,
ScriptRunner needs to be a stay-open):
ScriptRunner - a stay-open
property XLib : missing value
set XLib to missing value
on runScript(theScript)
set my XLib to (load script alias "SomePath:aLib.scpt")
run theScript
quit
end runScript
aLib.scpt - a compiled script
on runTest()
say "a Lib"
end runTest
Main - a script to be run in Script Editor
script myScript
property parent : application "ScriptRunner"
-- my XLib's runTest() -- fails!
-- runTest() of my XLib -- fails!
tell my XLib to runTest() -- works!
end script
tell application "ScriptRunner" to runScript(myScript)
Paul also noticed that the parent declaration isn't needed in the main
script for the "tell my XLib to runTest()" to work:
Main - variant 1
script myScript
tell my XLib to runTest() -- works!
end script
tell application "ScriptRunner" to runScript(myScript)
This works because of AppleScript's scoping rules.
In the above context, the "my" keyword just tells to look for a property
(or... a global, whichever first encountered) named "XLib".
Such a binding occurs at run-time; so, entity XLib doesn't need to be
provided by Main's context istelf, but may be built during execution:
Main - variant 2a
-- Just mirroring variant 1
script myScript
say (class of my XLib as string)
end script
tell application "ScriptRunner" to runScript(myScript)
--> "script"
Main - variant 2b
-- Explicitely providing XLib in Main's context
property XLib: "hello"
script myScript
say (class of my XLib as string)
end script
tell application "ScriptRunner" to runScript(myScript)
--> "string"
Main - variant 2c
-- Telling to look for XLib into another context
property XLib: "hello"
script myScript
property parent: application "ScriptRunner"
say (class of my XLib as string)
end script
tell application "ScriptRunner" to runScript(myScript)
--> "script"
I suppose the above illustrates what has meant by writing:
"Nothing to do with inheritance or loaded libraries; you just need
to send the 'get' event at the right place. You're dealing with plain
old AppleScript here, not the Apple Event Object Model[...]".
Anyway, let's just reason in terms of AppleScript's language.
The above illustrate basic scoping rules, but shows NOTHING about objects.
The confusing part is that AppleScript implements its object-oriented
capabilities with the help of such scoping rules, and thus with keywords
such as "parent" or "my".
So, back to our (scoping-based) business.
This variant is just the original Main script, without the unneeded
parent declaration:
Main - variant 3
script myScript
-- my XLib's runTest() -- fails!
-- runTest() of my XLib -- fails!
tell my XLib to runTest() -- works!
end script
tell application "ScriptRunner" to runScript(myScript)
We already know that, upon myScript's execution, "my XLib" is somehow
recognized as a script.
The two failing statements have something in common: syntactically, they
try to directly access a feature of something that should be an object.
Moreover, in the present case, we expect that feature to be recognized
as a handler.
But this also supposes that "my XLib" is already a fully-fledged script
object.
By contrast, the succeeding statement explicitely provides a context for
the interpretation of "my XLib" as an object.
Notwithstanding the initialization work that comes with a "tell" statement.
Hence the idea of providing the first two statements with a "tell"-like
context through a prior evaluation; for example:
Main - variant 4
script myScript
(get my XLib)'s runTest() -- works!
runTest() of (get my XLib) -- works!
tell my XLib to runTest() -- works!
end script
tell application "ScriptRunner" to runScript(myScript)
(note that with the above, we should be running three distinct instances
of aLib.scpt...)
I'm sure someone will provide a better/more detailed explanation.
In the meantime, hope this somewhat helps,
Axel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden