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: Thu, 18 Jul 2002 15:03:22 +0100
Nigel Garvey wrote:
>
> tell objectFoo to doOwt()
>
>
With my idea, you just write 'doOwt()'.
Perhaps I'm just getting old, but I regard this as being much less an
advantage than I might once have. Increasingly, I'd say it was the other
way about.
>
>I guess you could hide sub-handlers within a main handler by wrapping them
>
>in a script object, but I'm not sure what practical advantages this'd have
>
>(anyone think of any?).
>
>
The original idea wasn't so much to hide the sub-handler as to tidy it
>
up.
(I say poh-tate-ho, you say po-tat-oe... same thing.:)
>
I had a recursive handler that took two parameters, one of which
>
didn't change from iteration to iteration and had exactly the same
>
calculations performed on it each time - which I found very annoying. The
>
obvious answer was to have a 'front end' handler that pre-calculated the
>
repeated stuff and passed the result to another handler, which recursed
>
upon itself without having to repeat the calculations. That meant having
>
two handlers in the script, one of which merely existed as a detached
>
portion of the other. By putting the recursive portion into a script
>
object within the header portion, the process was tidied up into one
>
handler. It's a bit like having the engine under the bonnet instead of on
>
a support trailer nearby.
Personally, I don't see a problem with having two handlers in a script
instead of one. The easiest way to avoid having lots of handlers in a
script - if that's all you're after - is simply to put all of your code
into one big 'run' handler. However, having one handler versus a dozen
doesn't automatically make your script structurally simpler, or easier to
test, read or maintain. If your project needs more structure than handlers
alone provide, use modules. If it needs even more than that, use OOD.
If there's a Fear Of Handlers amongst folks, it's misplaced. Handlers
shouldn't be regarded as a last resort when all else has failed; something
to be embarrassed about. So why hide them away like you're ashamed? Apply
the KISS principle [and, where necessary, a simple naming scheme], and
don't be too quick to jump through hoops simply to satisfy some
aesthetic/perceived need. Else I shall be forced to say words like
"coupling" and "cohesion", which I don't really understand either but they
make me appear big and intimidating, until you repent.;p
>
>It's certainly a very strange way to go about
>
>hiding things from the user; a more traditional class-based OO language
>
>wouldn't even support such a heretical(?) approach.
>
>
That's one reason I like AppleScript. Its users aren't forced to conform
>
to other people's orthodoxies. It suits people of many agendas. :-)
Mmmm... Well, I hate to be the wet blanket, but the bigger and more
ambitious and complex my projects become, the less inventive and more
"orthodox" my coding style becomes. Not for lack of creativity I would
hope, but having cut myself with Occam's Razor a few too many times I'm
beginning to find that there are times and places where being artistic and
original is a Very Good Thing, and times and places where it's most
generally not. Be happy to quote cases.
(After all, you could just as easily call it as using robust, established
techniques that have been heavily time-tested and thoroughly proven over
many years by thousands of folk who are far, far smarter and experienced
than me. Just to put another perspective on it.:)
Cheers,
has [aka "Committee For The Defense Of One-Line Handlers"]
--
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.