Re: Passing *possible* variables to a handler
Re: Passing *possible* variables to a handler
- Subject: Re: Passing *possible* variables to a handler
- From: Nigel Garvey <email@hidden>
- Date: Thu, 18 Jul 2002 02:26:15 +0100
has wrote on Wed, 17 Jul 2002 13:53:46 +0100:
>
Nigel Garvey wrote:
>
>
>... I asked [Arthur] what he thought
>
>of an idea I'd had that if a handler depended on one or more private
>
>subhandlers, it would be tidier to stick these in a script object inside
>
>the main handler
>
>
This sounds sort of like OO Design principles, only backwards. In OOD you
>
encapsulate all the related handlers in the script object, indicating which
>
handler(s) are for public use and which are private [1], so that anyone can
>
call the public handlers [methods] from outside by referencing the object:
>
>
tell objectFoo to doOwt()
With my idea, you just write 'doOwt()'.
>
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 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.
>
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. :-)
NG
_______________________________________________
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.