Re: Inheritance and Loaded Libraries
Re: Inheritance and Loaded Libraries
- Subject: Re: Inheritance and Loaded Libraries
- From: Axel Luttgens <email@hidden>
- Date: Tue, 02 Nov 2004 19:11:26 +0100
(Sorry, I had a formatting problem - reposting)
David Weiss wrote:
> Let me provide more detail.
While I was still trying to understand that gorgeous detail, has already
provided you with his analysis; I wouldn't say I totally disagree with
him ;-)
But, on the other hand, one may also postulate that you know what you
are doing ;-)
And you asked a question; so, here follows an attempt to answer to that
question.
In the hope to be of some help in making a decision.
In the following, I kept only two libraries ("XLib" and "PrefLib").
They are loaded by a stay-open application named "big".
A script "big.scpt" invokes those libraries through the stay-open.
Let's begin with a revised version of your library "XLib".
In fact, there are very few changes; see the comments.
This is script "XLib.scpt"
==========================
-- Enclose the whole matter into a wrapper script.
-- This will allow to avoid keywords such as "my" whose versatility
-- may lead to confusions at compile time; use "thisOne" and "parent"
-- instead.
script thisOne
-- When loaded into application "big", the parent will be
-- application "big".
-- So, no need to declare the parent here.
property identifier : "XLib"
property name : "XLib"
-- Just a cosmetic matter... ;-)
on doErr(lib, what)
error "access to " & lib & "'s " & what & " from " &
thisOne's name & " failed"
end doErr
on functionTest()
return thisOne's identifier
end functionTest
on accessProperties()
if thisOne's name is not "XLib" then thisOne's doErr("XLib",
"name")
if parent's PrefLib's name is not "PrefLib" then thisOne's
doErr("PrefLib", "name")
-- I don't understand why you would want to access the
-- calling script ("test") here.
-- After all, "test" is a client for your various libraries;
-- those libraries should be independent of the clients they
-- serve... otherwise, just write a big app and don't even
-- bother with libraries ;-)
if parent's identifier is not "ParentObject" then thisOne's
doErr("parent", "identifier")
end accessProperties
-- Note the "tell parent's..." when calling another lib's
-- function from here.
on testFunctions()
-- No looping anymore here:
if thisOne's functionTest() is not "XLib" then thisOne's
doErr("XLib", "functionTest()")
tell parent's PrefLib to if functionTest() is not "PrefLib"
then thisOne's doErr("PrefLib", "functionTest()")
-- As above, no reasons to access script "test" here.
if parent's functionTest() is not "ParentObject" then
thisOne's doErr("parent", "functionTest()")
end testFunctions
end script
Library "PrefLib" is just rewritten the same way:
This is script "PrefLib.scpt"
=============================
script thisOne
property identifier : "PrefLib"
property name : "PrefLib"
on doErr(lib, what)
error "access to " & lib & "'s " & what & " from " &
thisOne's name & " failed"
end doErr
on functionTest()
return thisOne's identifier
end functionTest
on accessProperties()
if parent's XLib's name is not "XLib" then doErr("XLib", "name")
if thisOne's name is not "PrefLib" then doErr("PrefLib", "name")
if parent's identifier is not "ParentObject" then
doErr("parent", "identifier")
end accessProperties
on testFunctions()
tell parent's XLib to if functionTest() is not "XLib" then
doErr("XLib", "functionTest()")
if thisOne's functionTest() is not "PrefLib" then
doErr("PrefLib", "functionTest()")
if parent's functionTest() is not "ParentObject" then
doErr("parent", "functionTest()")
end testFunctions
end script
Let's now define "big". In fact, this is just a regular script application:
This is stay-open "big"
=======================
property identifier : "ParentObject"
-- Just kept two libraries.
property XLib : missing value
property PrefLib : missing value
-- I suppose this is to be replaced by an on-demand loading mechanism...
on initialize()
set XLib to thisOne of (load script alias "Some:path:XLib.scpt")
set PrefLib to thisOne of (load script alias
"Some:path:PrefLib.scpt")
end initialize
on doErr(lib, what)
error "access to " & lib & "'s " & what & " from " & my
identifier & " failed"
end doErr
on functionTest()
return my identifier
end functionTest
-- I suppose you conceive such a function as some kind of library
maintenance tool?
on testFunctions()
if my XLib's functionTest() is not "XLib" then doErr("XLib",
"functionTest()")
if my PrefLib's functionTest() is not "PrefLib" then
doErr("PrefLib", "functionTest()")
if functionTest() is not "ParentObject" then doErr("big",
"functionTest()")
end testFunctions
And now the client script. It may just be viewed as a regular script
targeting an application:
This is script "big.scpt"
=========================
-- Let's just be a client of libraries loaded into "big".
-- Which of course doesn't mean we may not have our own
-- properties and handlers.
property identifier : "test"
on functionTest()
return my identifier
end functionTest
tell application "big"
initialize()
its XLib's name
its PrefLib's name
its identifier
my identifier
tell its XLib to accessProperties()
tell its PrefLib to accessProperties()
tell its XLib to functionTest()
tell its PrefLib to functionTest()
its functionTest()
my functionTest()
-- It seems you forgot to call that one... ;-)
it's testFunctions()
end tell
So, it seems to be feasible, the main requirement being to follow
systematic rules while writing the various libraries.
Such a requirement doesn't seem to be untractable.
This doesn't mean that there won't be restrictions. For example, I
didn't explore the loading of two libraries "A" and "B", "B" being "A"'s
parent; should be possible, but would it be practical?
Of course, your initial example was a real spaghetti - (TM) has.
But I suppose this just resulted from an experimental stage, not from
any real work.
And it shouldn't be too difficult to follow has' recommendations (rules)
within above framework.
He also spoke about another approach at AppleMods; could be worth to
compare both approaches, and to see which one could better suit your needs.
HTH,
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