Re: Please Pass the Handler
Re: Please Pass the Handler
- Subject: Re: Please Pass the Handler
- From: has <email@hidden>
- Date: Mon, 14 Jan 2002 14:38:13 +0000
Michael Sullivan wrote:
>
>
> In some programming languages, you can pass a handler, (function or
>
> subroutine), to another handler, so that the passed handler can
>
> provide custom functionality. A typical example would be JavaScript's
>
> sort() method of arrays, where you pass a comparison function that
>
> tells sort() how to compare any two items in the array.
>
>
You are my alter-ego.
Heh, and you must be mine. I've been pondering how to implement a quicksort
function that would allow custom sorting and filtering to be done at the
same time. I'd be interested to know what you come up with.
>
I had the exact problem you did and found the workaround where you pass
>
a script object instead of directly passing a handler. That got it to
>
work in the simple test situation, but in my actual program, if I tried
>
to sort a list longer than a few items, I ended up with a stack
>
overflow.
Have you tried the assigning-the-handler-to-a-top-level-property approach?
That might work better, as it doesn't require bogging down the qsort's
loops with passing script objects.
>
If it is, I realize
>
that qsort can be implemented with loops though IIRC it's a serious
>
brain-buster to follow. Maybe one of my old algorithms books has the
>
necessary code.
I'd be interested to see if you came up with a non-recursive quicksort.
I've tested Serge's quicksort against both a binary insertion sort and a
bubble sort for interest, and the damn thing's so fast it's done before the
other two have even started.<g> So, needless to say, a totally unbreakable
qsort would be my absolute idea of heaven.
>
> One way to avoid using a top-level script object, and to get
>
> away from the calling handler having to know the name of the
>
> passed-handler, is to simply have the calling handler create
>
> it's own script object:
>
>
> on PassThisHandler()
>
> return "Successful !!!"
>
> end PassThisHandler
>
>
> on CallTheHandler( handlerParameter )
>
>
> script HoldAHandler
>
> property theHandler : handlerParameter
>
> end script
>
>
> return theHandler() of HoldAHandler
>
>
> end CallTheHandler
>
>
> CallTheHandler( PassThisHandler ) --> "Successful !!!"
>
>
> I think I like this method the best, as it allows the calling
>
> handler to define it's own names for things, ie: it doesn't
>
> have to know that the handler's defined-name is PassThisHandler.
>
>
I like this. I don't quite understand the design of *why* this works
>
but standard passing of a handler parameter doesn't, but this gives the
>
client interface I'm looking for. I also don't like the idea of having
>
the restrict the client name of the handler.
Something to do with AS's scoping rules, I'd guess. I think it must only
look within script objects to find a handler, not within other handlers.
Anyway, for what you're doing I'd suggest trying the
'dump-handler-into-top-level-property' approach and see if that works
better (as it's the least fancy):
property _comparisonHandler : {}
on quicksort(theList, comparisonHandler)
set _comparisonHandler to comparisonHandler
_qSort(theList)
end
on _qSort(theList)
--do quicksort, calling _comparisonHandler(params) to do your comparisons
end
Cheers,
has