Re: Please Pass the Handler
Re: Please Pass the Handler
- Subject: Re: Please Pass the Handler
- From: has <email@hidden>
- Date: Mon, 14 Jan 2002 14:34:38 +0000
Arthur J Knapp wrote:
>
In AppleScript, it has been shown that a handler can be passed
>
around as a parameter, but that the act of actually calling the
>
handler is complicated by AS's bizarre variable-scope rules.
I wouldn't mind seeing some decent diagrams of how AS's scoping rules work.
It's kinda hard to visualise it all in my head. Anyone know of any?
>
One way to deal with the scope problem is to have the calling handler
>
set it's parameter to a top-level property:
[...]
>
This seems to work because, (I guess), properties and handlers share
>
the same scoping rules in AppleScript. The major problem with the
>
above technique is the set/restore procedure. I suppose you don't
>
*have* to clear the passed-handler from the property, but it seems
>
like good coding practice to do so.
This is how I've been doing it so far, though I can't say I'm bothered
about flushing the property afterwards. (As far as I can tell, there's no
data copying involved - everything just points back to the original handler
object, - so it won't bloat the script object or anything.)
>
One way to avoid using a top-level script object, and to get
>
away from the calling handler having to know the name of the
>
passed-handler, is to simply have the calling handler create
>
it's own script object:
[...]
>
I think I like this method the best
I'm inclined to agree. Keeping the scope as restricted as possible seems
like a sensible idea - its fewer wires to risk getting crossed.
>
In any case, I just realized today that there is yet one more
>
trick that can be used:
[...]
>
Notice, we've gone back to passing a script object, but we
>
don't have to create a script object, because *me* is a
>
script object, refering to your entire script!!!
BTW, Scott Norton demonstrated this technique in a reply to one of my dumb
questions a couple weeks back. If you want to go dig it out for a read, the
subject line was "OO Programming (kinda like BDSM...)". (It took me five or
six readings before I managed to make sense of it all;p ...but it was worth
it.)
"Me" is great fun. I've designed a number of objects containing a clone()
function, allowing them to return a duplicate of themselves for further
use. It's just a case of: 'copy me to newObj/return newObj'. Pretty
convenient when you've got an object that needs to clone itself as part of
its operation (in my case, recursively parsing a tree structure; it seems
to work very well too).
There is one curious(?) thing I've noticed about using copy to clone
objects: anything which is inherited via the parent property gets copied
too. This caught me out at first: the parent object was shared across
several objects, so when one of those objects got cloned, any changes it
might make to the inherited (shared) properties weren't reflected across
the others.
Not what I'd intended at all (though I've since taken advantage of this
behaviour elsewhere), and it had me scratching my head till I went and
built and tested some prototypes to understand what was going on. (Once I
did, I changed this particular design to use a constructor function and it
works perfectly now.)
Still, it's something to bear in mind when considering whether to use
"copy" to clone an existing object, or a constructor function to create a
new one.
>
At least one good reason would be when working with script
>
libraries, ie: you've loaded a compiled script via the
>
"load script" command. These loaded scripts, unfortunately,
>
do not have access to your script's top-level namespace. By
>
passing "me" as a parameter, you've given the loaded script
>
complete access:
Ah yes, that was the dumb question.:)
>
P.S. If I've confused everybody, I'm sorry. Scott Norton will
>
no doubt set things straight once he reads this. :)
I think we should just lock Scott in a room until he writes us all a book
that explains it all. ;)
Cheers,
has