Re: script object property contamination
Re: script object property contamination
- Subject: Re: script object property contamination
- From: has <email@hidden>
- Date: Wed, 13 Feb 2002 13:37:23 +0000
Anthony Adachi wrote:
>
>It's half of the solution. The other half is to rework your code so that
>
it
>
>actually does what you want, instead of what you're currently telling it
>
to
>
>do.
>
>
I think you have misinterpreted the whole point of my original post. My
>
point was to bring to light this bug.
Hah, well that's true enough. My bad.:) I actually thought your original
post was complex working code that you'd discovered the problem in and
posted to show the rest of us.
So you don't need to worry about fixing it after all. ;)
>
As I said before, I have already found a work around to this problem. My
>
solution was to use globals instead of properties.
>
>
For example, in the script below, the handler calls return the same results
>
when the get_first_global() handler gets invoked regardless of whether or
>
not that handler was called dynamically. As well, the keyword 'my' is not
>
required to get correct results.
I believe the 'my' keyword is the 'proper' device to use when a handler in
one script object gets a property from another script object that's linked
via inheritance:
======================================================================
script a
property c : 4
end script
script b
property parent : a
on d()
get my c -- (i.e. 'get c' alone won't work)
end d
end script
tell b to d()
======================================================================
The ASLG is less than crystal in this area, but it seems to indicate this
is the general idea.
--
>
tell Grab_globals_Test to initialize()
>
tell Grab_globals_Test to get_first_global()
>
--->"Value in Chlild"
>
set Grab_globals_Test's performTestMethod to Grab_globals_Test's
>
get_first_global
>
tell Grab_globals_Test to performTestMethod()
>
-->"Value in Chlild"
(Oh hey, now you're cheating - last time you were directing 'tell's at
aParent. No fair!;)
I actually find your latest script a bit worrying - it does seem to give
you the response you're after, but I'm trying to figure out *how*.
The change in behaviour when you use global declarations is interesting -
it may be that there's some subtle difference in how global declarations
are scoped to how properties are scoped.
Exploring further, I stripped down your script in a process of elimination.
In particular I removed the inheritance relationship between to two script
objects so that they're now *completely independent* of one another:
======================================================================
script aParent
to performTestMethod()
end performTestMethod
end script
script Grab_globals_Test
global FirstChildProp
to initialize()
set FirstChildProp to "Value in Chlild"
end initialize
to get_first_global()
return FirstChildProp
end get_first_global
--property parent : aParent
end script
tell Grab_globals_Test to initialize()
set aParent's performTestMethod to Grab_globals_Test's
[NO-BREAK]get_first_global
tell aParent to performTestMethod()
-->"Value in Chlild"
======================================================================
This behaviour disturbs me. It's clearly has nothing to do with the
inheritance mechanism, so there's clearly something strange going on. It's
as if the get_first_global now has some sort of 'ancestral memory' that it
takes with it on its travels to aParent. Even though it's now in a
*completely different* context, it somehow seems to worm its way back to
fetch the contents of Grab_globals_Test. [I could hypothesise what's
happening here, but it'd be pure guesswork and little practical use.]
So I suspect your 'globals' approach is also exploiting the flaws in the
static scoping system. I can't say for sure (just making an educated
guess), and I doubt anyone outside of the AS team could really tell you.
Perhaps you could try taking this problem directly to them and see if
they'd be willing to look into it?
--
>
Take the script below for instance. The 'hard coded' call to the child's
>
get_first_property() returns a correct result of "Property in Chlild".
>
Note that the keyword 'my' is not neccessary.
>
>
However, if one uses the dynamic handler
[BTW, I'm curious if "dynamic handler" is an official term for this sort of
pushing-handlers-around stuff, or just something you thought of to describe
it. I really don't know what the correct terminology for this is and would
find it handy if I did.]
>
Namely, the value store in the parent's FirstParentProp gets returned
>
rather than the child's FirstChildProp. This most definatly a bug
Yep. Did you read my first post, which theorised as to why this was happening?
>
If you take a closer look at the long example script in my original post
I'd rather not - it hurt my brain trying to read it last time. ;)
>
This kind of contamination of it's properties by it's parent should not
>
occur and is not likely a intended 'feature' of the AppleScript language.
Indeed. As I said originally, it's [almost certainly] due to a flaw of the
static scoping that's done at compile-time. Either the AS designers
completely overlooked the possibility that a few raving nutters like
ourselves would start tossing handler objects around willy-nilly, or they
figured that a safer *but slower* implementation wasn't worth doing for
those few nutters' sakes alone and made the tradeoff deliberately.
>
At this stage there seems to be at least two work arounds. Either through
>
the usage of 'my' (as you've demonstrated) or through the usage of globals
>
(as in the example I cited).
As you can tell, I'm a bit uncomfortable with your method since I suspect
it to be a bug exploit itself [1]. I think I'd recommend sticking to 'my'
keywords, though if you do manage to find out anything concrete from the
horse's mouth then I'd be interested to hear.
Cheers,
has
[1] (Of course, this means Arthur's now going to invent 101 mind-boggling
new uses for it. But at least this time it won't be MY fault if he hurts
himself on it.;p)
_______________________________________________
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.