Re: handler failure [oops! correction]
Re: handler failure [oops! correction]
- Subject: Re: handler failure [oops! correction]
- From: Axel Luttgens <email@hidden>
- Date: Sat, 16 Nov 2002 13:11:04 +0100
(don't know what's happening with my posts, as well as with those from
other people: the order of arrival appears to be very anarchic at the
moment; hope this one won't be too redundant)
has wrote:
[snip]
I've noticed several other variable binding problems with AS, including this:
======================================================================
on foo()
return _val
end foo
property _val : 1
foo()
======================================================================
which is very bad;
At least, I think that this very old behavior of AppleScript may be
considered as being documented.
Yes, yes, it happens.
Even if, as usual, it requires heavy headaches to find it out throughout
the ASLG (but that's another point).
That said, I'm not sure one could call this a bad behavior; on the
contrary, GIVEN THE LANGUAGE, I'm of the opinion it is a wise
implementation decision.
When one writes:
on foo()
return _val
end foo
_val is either a local variable or a property.
If there was not that lexical scoping restriction (the one that requires
the property to be declared earlier in the script's code, before the
handler's declaration), ANY handler would really be in great danger.
(again, I insist on that point, I'm reasoning here GIVEN THE LANGUAGE,
as I will do everywhere in this post)
and this:
======================================================================
script a
property _val : 1
end script
script b
property parent : a
on foo()
return _val
end foo
end script
b's foo()
======================================================================
which is a perennial annoyance;
Again, I slightly disagree.
If "_val" in handler foo referred to the "_val" in script a, wouldn't it
be a great OOP problem?
Any script object would then be endangered by a programmer's decision:
to use that object as a parent for another object, the latter then being
able to clutter it's parent logic.
I think the observed behavior is needed in a language ***where a class
definition is also an instance definition***.
(as a side note: it is often complained about AppleScript that it
doesn't implement privacy for script objects; well, here we have some
kind of)
Second, this is documented too.
Well, very concisely (as usual for the truly important aspects of the
language)
And only if I correctly interpret the "(hidden)" in that sentence (ASLG
p.332):
If the child does not have its own definition of
a property or handler, it uses the inherited (hidden)
property or handler.
Third, this is a consequence of the lexical scoping convention: after
all, from script b's viewpoint, property "_val" isn't declared at all.
So, again, this is documented (ok, badly), and consistent within the
language's framework.
and this:
======================================================================
script a
property _val : 1
end script
script c
property _val : false
script b
property parent : a
on foo()
return _val
end foo
end script
end script
c's b's foo()
======================================================================
which is downright stupid.
Well... do you guess what I will write? ;-)
And I can do it very shortly, now:
The only "_val" foo is aware of is the one lexically declared before
foo's declaration, isn't it?
_______________________________________________
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.