# from Michael G Schwern on Monday 24 October 2011 22:12:
>Plan A...
>2) The old one is squirreled away in a stack.
>3) The new handler is told how deeply it's nested.
>...On the down side, every handler needs a delegator ... yucky. ...
>
>Plan B... when a subtest_start happens...
>
>1) An event handler creates a new one of itself (the subtest handler)
>2) The subtest handler is told how deeply nested it is.
>3) The parent handler stores itself in the subtest handler.
>4) The parent tells the event coordinator to remove itself and add the
> subtest handler instead.
>...
>On the down side, the event coordinator needs a "swap me out" method
> for event handlers.
I like the sound of plan B, except for the "stores itself in" combined
with "swap me out".
Can the event coordinator keep a stack? At the point where the parent
handler has to tell the coordinator "swap me out", you could have the
coordinator providing the functionality which you were thinking of
getting from the delegator.
How much freedom you want to allow the handlers in subtest_start() and
subtest_end()? If a subtest handler is "standard procedure", perhaps
the construction/destruction/stack is 100% managed by the coordinator
(or with some constrained flexibility like taking a classname and
arguments from the return of subtest_start() -- or even pass in a
messenger/knob if that fits better than using the return values.)
> The code to handle the creating and swapping of a subtest could be put
> in the event handler superclass.
Would that be for convenience of reuse or because an essential part of
the API is the freedom to override that method and do it differently?
I think putting this in the coordinator would allow fewer surprises.
--Eric
--
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
--Donald Knuth
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
