Re: Handler query - exchanging values
Re: Handler query - exchanging values
- Subject: Re: Handler query - exchanging values
- From: Axel Luttgens <email@hidden>
- Date: Fri, 30 Jun 2006 16:20:04 +0200
On 30/06/06 10:05, Shane Stanley wrote:
And I still can't see why you think such a
drastic change in behavior would be a good thing.
While not that drastic (well written scripts would not have been
affected), it would have been a (very, very) slight move towards the
right direction as far as AppleScript's scoping rules are concerned.
A slight one, as lots of other questionable behaviors would have
persisted anyway.
But an interesting one, as it might have been indicative of some
attempts at Apple's.
On 30/06/06 11:09, Yvan KOENIG wrote:
May I get explanations about the sentence:
-- (fortunately) fails since 10.4.x
I see nothing making the "old" behaviour a bad one.
Note that my first script is representative of the "old" behavior too;
it just looks cleaner than the second one, by not relying on doubtful
scoping rules.
Now, while writing "fortunately", I was in fact thinking at the various
dangers brought by the rather loosy and sometimes ambiguous nature of
the language.
In that sense, any attempt to remove some of its ambiguity could be
viewed as "fortunate"...
If you allow, I'll illustrate the various points I was thinking at
through some short examples.
Of course, they should be transposed to projects of some size to see how
one may easily get catched.
-- Here, apples is local to boo().
set apples to "set in implicit run handler"
on boo()
set apples to "set in boo()"
end boo
boo()
apples
--> "set in implicit run handler"
-- Rather logically, apples is local to boo() here too.
on boo()
set apples to "set in boo()"
end boo
set apples to "set in implicit run handler"
boo()
apples
--> "set in implicit run handler"
-- Again, apples is local to boo().
on boo()
set apples to "set in boo()"
end boo
global apples
set apples to "set in implicit run handler"
boo()
apples
--> "set in implicit run handler"
-- With this one, apples is explicitely made non local to boo().
on boo()
global apples
set apples to "set in boo()"
end boo
set apples to "set in implicit run handler"
boo()
apples
--> "set in boo()"
-- And here, apples is non local because of lexical scoping.
global apples
on boo()
set apples to "set in boo()"
end boo
set apples to "set in implicit run handler"
boo()
apples
--> "set in boo()"
Above examples might look rather surprising to people not familiar with
AppleScript, wouldn't they?
What about this one then:
-- apples is local to hoo() and non local to boo().
on hoo()
set apples to "set in hoo()"
end hoo
on boo()
global apples
set apples to "set in boo()"
end boo
boo()
hoo()
apples
--> "set in boo()"
-- Looks like variables are, by default, local to handlers.
-- Really? ;-)
on run
set apples to "set in explicit run handler"
boo()
apples
end run
on boo()
global apples
set apples to "set in boo()"
end boo
--> "set in boo()"
Now, one may observe similar scoping rules with properties too.
For example:
on boo()
set apples to "set in boo()"
end boo
property apples : "property initializer"
boo()
apples
--> "property initializer"
property apples : "property initializer"
on boo()
set apples to "set in boo()"
end boo
boo()
apples
--> "set in boo()"
Add to the above the variations allowed with the keyword "my", in
addition to "global", "local" and "property".
Shake very hard, and then just keep these two short, yet intriguing ones:
-- What does boo() access? A global? A property?
on boo()
set my apples to "set in boo()"
end boo
set apples to "set in implicit run handler"
boo()
apples
--> "set in boo()"
-- Same question here.
on boo()
global apples
set apples to "set in boo()"
end boo
property apples : "property initializer"
boo()
apples
--> "set in boo()"
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