Re: Passing *possible* variables to a handler
Re: Passing *possible* variables to a handler
- Subject: Re: Passing *possible* variables to a handler
- From: has <email@hidden>
- Date: Mon, 15 Jul 2002 10:46:11 +0100
Paul Berkowitz wrote:
>
1) I see I'm going to have to study all this. I still can't make out what's
>
going on, but I'll try. I really will. Uggh.
It's really very simple:
-------
1. I stumble across something vaguely interesting and mention it to the list.
2. Straightaway Arthur lets out a mighty "Woo-Hoo!" and immediately cooks
up a hundred brilliant and terrifying uses for it.
3. A day or so later, Chris N. posts to the list declaring it a known bug
exploit and threatening to patch it in the next release.
4. Arthur makes big puppy-dog eyes at Chris, who relents.
5. Realising the awful mistake I've made ever mentioning the thing, I don
sackcloth and ashes and spend the rest of my days wandering the list,
yelling "Hackish Kludge Considered Harmful!" at anyone I can corner.
6. The rest of the world pays absolutely no heed to any of it, and
continues about its business exactly as before.
;)
-------
Alternately, you bug and berate the lazy tossers who come up with this
crazy stuff till the write a manual for it so anyone can use it [without
having to know all the tedious details of what actually going on inside].
>
2) On a related topic, I think I've seen both of you (maybe just Arthur?)
>
shove script objects into properties of your main scripts, perhaps with a
>
'run script' thingy? Is this necessary/useful/whatever? When?
Oh, I never do it with 'run script' - it offends my minimalist nature.;)
"Whenever it seems useful" would, I guess, be the answer. Perhaps you're
referring to the shoving of values into properties at compile-time? This is
a useful technique when you want to create, say, a set of lookup tables for
some high-speed handlers, rather than have the handlers calculating values
each time around. Sure, you could do initialise the tables at runtime too,
but since the point of using lookup tables is to minimalise runtime in the
first place, you're much better off moving this stuff as far away as
possible. (IIRC, my conversionLib does this, although I don't recommend it
as a shining example of good coding practice in other respects.)
>
3) And finally - I have occasionally used the Serge technique in a handler
>
which itself is revisited many times in the main script's repeat loop. As
>
far as i can see, that means I'm having to constantly re-initialize the
>
embedded script object a zillion times. Would this be a situation where the
>
script object in the handler could just be initialized once and its values
>
(the list which forms its own property) replaced a zillion times instead?
In something like Serge's qSort, no: you still need to create a new object
each time you recurse. All my approach does is move some of the inherent
complexity out of your code (your quicksort or whatever) and into mine,
where you no longer have to think about it. [Which is useful if you're like
me and can never remember how it is you're supposed to construct the damn
thing, with script objects and tell blocks and 'my' keywords... or should
that be 'its' keywords(?)... etc.]
That's all OOD is, after all: just another tool for managing the infernal
complexity of programming tasks a little more easily [hopefully!;].
HTH
has
--
http://www.barple.connectfree.co.uk/ -- The Little Page of Beta AppleScripts
_______________________________________________
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.