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: 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()
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?). 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.
>
on handler1(val1, val2)
>
script obj
>
property prop1 : val1
>
property prop2 : val2
>
>
on privateHandler(val3) -- dummy handler :-)
>
[...]
>
end privateHandler
>
end script
>
end handler1
Ey lad, looks like you've almost incidentally discovered constructor
functions (except that your example above doesn't actually return the
script object created). These are described on p329-331 of ASLG [2] if
you're interested. (The ASLG also _completely_fails_ to indicate why such
things might ever conceivably be useful. Typical...;p)
HTH
has
[1] AS has no built in concept of private vs public, so the simplest
solution is to use a standard naming scheme, where public methods are of
form "foo()" and private methods are of form "_foo()". (Ditto for
properties.)
[2] Note that the second last para on p329 reads:
>
If you include a script object definition at the top level of a
>
script-that is, as
>
part of the script's Run handler-AppleScript initializes the script object
>
each
>
time the script's Run handler is executed. For more information, see "Run
>
Handlers" (page 303).
This is potentially misleading. If you declare the script object within an
_explicit_ run handler, it is indeed true. If you truly declare it at the
top level, ie outside the run handler (which is also the case if no
explicit run handler is declared), then the script object is initialised at
*compile-time*. [Note: this isn't a brilliant explanation either, but it's
still better than the ASLG one.]
--
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.