Re: handler failure
Re: handler failure
- Subject: Re: handler failure
- From: Axel Luttgens <email@hidden>
- Date: Thu, 14 Nov 2002 10:45:54 +0100
has wrote (13/11/02 14:35):
Chris Espinosa wrote:
A handler is essentially a property in your script, and you can set it
to any value, including that of another function.
Unfortunately, this [undocumented] behaviour has always been broken:
[snip]
When the handler object moves to a new context, it forgets its original
context (bad) and attempts to use the new one instead (worse). Mix in some
static bindings for laffs, and you can get some fantastically
incomprehensible results (...).
Paul Skinner wrote (13/11/02 16:31):
> On Wednesday, November 13, 2002, at 08:35 AM, has wrote:
>> [snip]
> [snip]
> The results are what I expected. And if they change I'll have to rewrite
> some scripts. Just exactly what did you think the contents of b's bar
> should be?
Well, both viewpoints can be justified.
Starting with has' original two scripts, one has:
Code #1:
script a
property _val : 1
on foo()
return _val
end foo
end script
script b
property bar : missing value
end script
class of a's foo
--> handler -- as expected
set b's bar to a's foo
class of b's bar
--> handler -- so, b's bar get evaluated to a handler; seems ok
b's bar()
--> handler foo -- b's bar execution doesn't really fail, but...
... but looks suspicious. Here's why.
Looking at the structure of a's foo, one sees that this handler expects
a property of its enclosing script.
So, let's try this:
Code #2:
script a
property _val : 1
on foo()
return _val
end foo
end script
script b
property _val : 2
property bar : missing value
end script
set b's bar to a's foo
b's bar()
--> 2
Aha. Now b's bar fully executes, and yields a result by using its own
context.
This immediately raises Problem #1:
b's bar execution within Code #1 should have raised an error (something
like "couldn't get some unknown value") but certainly not silently pass
a quite silly value
(unless such a behavior is intentional, in which case it should be fully
documented - Problem #1bis? ;-) )
Let's go somewhat further:
Code #3:
script a
property _val : 1
on foo()
return _val
end foo
end script
script b
property _prop : 2
property bar : missing value
end script
set b's bar to a's foo
b's bar()
--> 2
Huho. Same result as above, but clearly not a "reference by name".
How then does foo, as "transplanted" into script b, reference _prop?
Code #4:
script a
property _val1 : 10
property _val2 : 20
on foo()
return _val2
end foo
end script
script b
property _prop : 1
property bar : missing value
end script
set b's bar to a's foo
b's bar()
--> handler foo
Oh. Same behavior as with Code #1.
Well, let's have a look at this:
Code #5:
script a
property _val1 : 10
property _val2 : 20
on foo()
return _val2
end foo
end script
script b
property bar : missing value
property _prop : 1
end script
set b's bar to a's foo
b's bar()
--> 1
Aaah. Execution's again complete.
It seems that foo, within script a, uses the second property defined in
that script.
The same way it does when "transplanted" into script b.
In one word, we are facing some kind of "reference by position" (I
suppose this is the "static linking" has was speaking about).
In my opinion, this is Problem #2:
The ability to store a handler in a property (or, more generally,
a variable) and to invoke it through that property, as useful as
it may be, yet comes with a lot of ambiguities.
So, as far as the "transplanted" handler just uses local variables,
there shouldn't be any problem and Paul's assertion seems ok to me.
The problems arise as soon as the handler uses properties of its
enclosing script.
Now, I'm not sure this is easily solvable within an interpreted language
that allows indirect execution of handlers.
_______________________________________________
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.