Re: Inheritance
Re: Inheritance
- Subject: Re: Inheritance
- From: Axel Luttgens <email@hidden>
- Date: Sat, 17 Jan 2004 16:42:43 +0100
Wallace, William wrote:
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?
IMHO, it should set z to 4.
And just to be sure, I tried your code here; z is set to 4.
Now, I'm not sure what the interrogation mark in "z --> 4?" is for.
Did you get error messages and/or unexepected results? And, if yes,
which ones?
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?
According to the language definition, they are equivalent.
And indeed, I don't remember having encountered a case where they differ.
Seems to just be a means to improve a script's legibility ("passive" vs
"active").
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 [...]
Here is an attempt to sort your questions.
But I perhaps completely missed your point, in which case don't hesitate
to tell. ;-)
As you know, the purpose of a try block is to catch an error that could
occur in a statement between the "try" and "on error" statements, to
avoid the raise of an error and to allow the execution of the statements
beteween the "on error" and the "end try" statements instead.
From a lexical point of view:
... -- while executing statements
try -- one encounters a try block
set x to 5 -- do this
set y to 1/0 -- jump immediately to "on error"
... -- these are not performed
on error
... -- execute these ones
end try -- then continue here
...
In its simplified form, the try block doesn't have a "on error" part;
its purpose is then mainly to avoid the raise of an error:
... -- while executing statements
try -- one encounters a try block
set x to 5 -- do this
set y to 1/0 -- jump immediately to "end try"
... -- these are not performed
end try -- continue here
...
In the absence of a try block:
... -- while executing statements
set x to 5 -- do this
set y to 1/0 -- raise an error and halt
... -- nothing else get executed
...
Now, let's have a dynamic point of view, that of an erroring statement S.
If no "try" statement has been encountered before executing S, an error
will be raised and the script will halt.
If one or more "try" statements have been encountered before executing
S, the error will be catched (and eventually handled) through the
nearest try block, that is the one corresponding to the latest
encountered "try" statement.
In fact, it could be said that a "try" statement pushes an error
context, and that the corresponding "end try" statement pops that
context. If the error context stack is empty when an error occurs, the
script halts immediately; otherwise, the context at the top of the stack
would be used.
So, your idle's try block can't claim seniority upon a narrower try
block if there is one.
On the other hand, an error can "bubble up" only through statements
between the "on error" and "end try" statements of the nearest enclosing
try block; a stupid example:
... -- while executing statements
try -- one encounters a try block
set x to 1/0 -- jump immediately to "on error"
on error
set x to 2/0 -- it depends...
end
...
Of course, instead of that idiotic "set x to 2/0", you could have a call
to some script's handler or something even more complicated. The
question is to know whether, in case of a subsequent error, a try
statement would be encountered before the erroring statement or not;
and, if not, whether there is a pending error context or not.
Finally, the idea of putting the whole error treatment into a single
handler would somewhat go against the idea of modularity provided by
script objects. But this is just an opinion...
HTH,
Axel
_______________________________________________
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.