Re: Inheritance
Re: Inheritance
- Subject: Re: Inheritance
- From: Axel Luttgens <email@hidden>
- Date: Fri, 23 Jan 2004 00:36:37 +0100
[ === PART II === ]
So, we were busy with this one:
-- Example 9
property m: false
script a
tell my m to doThat()
end
tell a to run
--> Can't get doThat of false
and had to conclude that it has nothing to do with inheritance, as the
script's parent is the SE which has no property "m".
By contrast:
-- Example 11
script a
tell my m to doThat()
end
tell a to run
--> m doesn't understand the doThat message.
so that we are back to the "expected" behavior (ie. trying to find a
suitable property in the inheritance chain).
Let's have a look at this:
-- Example 12
script a
get my version
end script
tell a to run
--> "FU1-1.9.3"
-- Example 13a
property version: false
script a
get my version
end script
tell a to run
--> false
-- Example 13b
script a
get my version
end script
tell a to run
--> false
property version: false
In all cases, there is an inherited property, ie AppleScript's version. [4]
But if a variable bearing the same name is defined somewhere at the
script's top-level, the corresponding variable tends to be used.
Note that the "my" keyword isn't really needed for that rule to apply:
-- Example 14
script a
version
end script
tell a to run
--> "FU1-1.9.3"
-- Example 15a
property version: false
script a
version
end script
tell a to run
--> false
-- Example 15b
script a
version
end script
tell a to run
--> false
property version: false
but there are yet subtle differences when "my" is absent and when there
is no inherited property bearing a same name:
-- Example 16
script a
m
end script
tell a to run
--> The variable m is not defined
-- Example 17a
property m: false
script a
m
end script
tell a to run
--> false
-- Example 17b
script a
m
end script
tell a to run
--> The variable m is not defined
property m: false
In the last case, the absence of "my" and of an inherited property
induces lexical scoping: even if properties are evaluated before
script's execution, the definition of the variable must appear before
its use in the code...
Did I speak about AppleScript's dark side? [5]
But... I haven't yet said anything about global variables.
Quickly then:
-- Example 18
-- A variable implicitely defined as a global one
set m to false
script a
m
end script
tell a to run
--> The variable m is not defined
-- Example 19
-- A variable implicitely defined as a global one
set m to true
script a
my m
end script
tell a to run
--> true
-- Example 20
-- A variable implicitely defined as a global one
set m to true
script a
global m
m
end script
tell a to run
--> true
-- Example 21
-- A variable explicitely defined as a global one
global m
set m to true
script a
m
end script
tell a to run
--> true
Head scratching...
In fact, all those behaviors are generally quite consistent, but they
often require to think very hard while facing an unexpected behavior.
Incidentally, there is a morality: once you start a project of some
importance, BE DEFENSIVE in your programmation.
For example, whenever possible [6],
- avoid to define variables (globals and properties) at the TLS,
- don't rely on AppleScript's defaults, be instead explicit,
- define an explicit run handler instead of an implicit one,
- use globals only when you really need some data to be shared across
scripts objects
And the relationship with your original code?
(big relief in the assistance)
Well, should be clear now ;-)
When "main script" is run in SE:
-- script 1
-- This is not used at all.
to doIt()
set my parent's z to 4
end doIt
-- script 2
to suggestIt()
-- This will try to refer SE's m through inheritance
tell my parent's m to doIt()
end suggestIt()
--main script
property z : 3
-- These are two implicit globals
set m to (load script alias "path:to:script 1")
set p to (load script alias "path:to:script 2")
p's suggestIt()
On the other hand, when "main script" is run as an application:
-- script 1
to doIt()
-- This will refer to app's property z
set my parent's z to 4
end doIt
-- script 2
to suggestIt()
-- This will refer to app's global m
tell my parent's m to doIt()
end suggestIt()
--main script
property z : 3
-- These are two implicit globals
set m to (load script alias "path:to:script 1")
set p to (load script alias "path:to:script 2")
p's suggestIt()
In conclusion, even if the above lines of code use a lot of object
terminology, they finally have very few to do with inheritance.
Which was the theme of the thread.
Must be an illustration of the infamous "loi de la vexation universelle".
Sorry for having been so long, but I never managed to devise a concise
description of those subjects. Must be the price to pay for, on the
other hand, enjoying an otherwise rather handy programming environment.
And please be also indulgent in case of typos: I tried everything, but I
can't ensure that my copy/paste operations have allways been coherent...
Really Hoping This may have been of some Help,
Axel
[4] So, AppleScript itself appears somewhere in the inheritance path
too. This in fact isn't very surprising, as how could we otherwise be
able to invoke such things as "pi" or "tab"?
[5] The only way to sort out all those things is to go back to the ASLG
(the pages 311-322 are of particular relevance) and to experiment... And
there are a lot more of combinations to try: script objects defining
properties with names identical to those defined in the TLS, local vs
global variables, co-existing properties and globals bearing identical
names...
[6] Other people may suggest other ways, and programmatic style
questions may quickly lead to religious wars...
[ === END === ]
_______________________________________________
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.