Re: Inheritance
Re: Inheritance
- Subject: Re: Inheritance
- From: "Wallace, William" <email@hidden>
- Date: Thu, 15 Jan 2004 11:59:55 -0600
- Thread-topic: Re: Inheritance
Cool!
Thanks, JJ, that will help out a lot. However, there is one other wrinkle. What if:
--loaded script 1
to doIt()
set my parent's z to 4
end doIt
--loaded 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:loaded script 1")
set p to (load script alias "path:to:loaded script 2")
p's suggestIt()
z --> 4?
Shouldn't that work as well, or am I missing some aspect of this concept?
Also, I've defined all my handlers as "on <handler identifier>()" as opposed using "to <handler identifier>()". what is the distinction between the two? Is one construct better in certain situations?
And finally, I may be tripping my self up with some unnecessary complexity. My main script has an explicit run handler which loads a bunch of script objects and then an idle handler which periodically tests for certain conditions and then, based on the result, calls the handlers defined in the loaded script objects to perform a series of tasks. To further complicate matters everything is wrapped in "try" blocks and the "on error" handler for each try block calls a handler from one of the loaded script objects to handle the errors differently based on the circumstancess. This error handling script object's handler is itself wrapped in a "try" block which calls yet another script object's handler in the event of an error while handling the initial error. Will an error tend to "bubble up" through these nested "try" blocks and possibly yield misleading error attributes (part of my error handling subroutine tries to pinpoint the location of the error within the script and then log that info)?
For instance, if I have my idle handler wrapped in a "try" block and the idle handler calls a handler from a loaded script object which is wrapped in its own "try block, and an error occurs during the execution of the called script object's handler, will the idle handler's "try" block's "on error" handler (hunh?!!) claim seniority and handle the error exclusively or will the called script object's handler's "try" block's "on error" handler handle it exclusively or perhaps even handle it first and then hand it off to idle handler's yada yada yada...? Should I perhaps move the error handling subroutine into the main script?
Thanks again,
B!ll
PS - Does anybody else on this list get ocassionally un-subscribed for no apparent reason? This has happened to me four times in the past seven or eight months. I'm beginning to wonder if I should take it as a hint.
> Shouldn't a loaded script object inherit everything from the main script into
> which it was loaded.
No. It is a new instance of a script object with its own methods,
properties, etc.
> In other words shouldn't handlers within the loaded
> script object be able to see (and change the value of) variables declared as
> global in the main script? make use of handlers defined in the body of the
> main script? Or do I have to explicitly declare the main script as the parent
> of the loaded script object in order to inherit these things? If so, how does
> one refer to the top level script?
You must explicitly call "my parent". Eg:
#################### loaded script
to doIt()
set my parent's z to 4
end doIt
####################
#################### loader
property z : 3
set m to (load script alias "path:to:loaded")
m's doIt()
z --> 4
####################
If you use "set z to 4" in the doIt() handler, z won't be modified in the
"main" script.
jj
_______________________________________________
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.