Re: Passing *possible* variables to a handler
Re: Passing *possible* variables to a handler
- Subject: Re: Passing *possible* variables to a handler
- From: "Arthur J. Knapp" <email@hidden>
- Date: Thu, 18 Jul 2002 15:16:44 -0400
>
Date: Wed, 17 Jul 2002 13:53:46 +0100
>
From: has <email@hidden>
>
Subject: Re: Passing *possible* variables to a handler
>
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
>
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?).
First of all, there is the Serge effect, where a script object might be
needed by a handler for only the life of the handler for speeding up access
to list items. Rather than referencing the object directly, one can use
"Nigel" access, giving the script object methods that provide faster access:
on TheHandler( theList )
script o
property p : theList
on GetAt(x)
return my p's item x
end
end
tell o
GetAt(4) --> faster access to item 4
Secondly, Nigel was attempting to find different ways to make "tidy"
code, and this was an experiment at giving a single handler it's own
reusable "supporting" handlers within itself. It is actually very
similar to a new concept in the latest verions of Mozilla's JavaScript
engine, where functions can "nest" their own functions:
// Silly example of nested functions:
function AddSquares( a, b )
{
function square( x )
{
return x * x;
}
return square( a ) + square( b );
}
a = AddSquares( 2, 3 ) // returns 13
b = AddSquares( 3, 4 ) // returns 25
c = AddSquares( 4, 5 ) // returns 41
>
... 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.
Gosh Has, when did you become this pedantic, dogmatic purveyor of the
status quo?
;-)
>
> 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).
???
Sure it does:
on hand()
script o
property p : 3.14159
end
end
hand() --> <<script o>>
Initialized script objects return a result just like any other
data type on a line by it self:
script
property o : 3.14159
end
set obj to result --> <<script>>
{ Arthur J. Knapp, of <
http://www.STELLARViSIONs.com>
a r t h u r @ s t e l l a r v i s i o n s . c o m
}
_______________________________________________
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.