# from Michael G Schwern
# on Wednesday 26 October 2011 09:51:
>> Note that you should be able to allow e.g. "the new subtest object
>> is just a copy of me" and other advanced usage without ceding all of
>> the mechanics to the handler object.
>
>Ooh, good idea. I think that's the clincher right there. If a
> handler can effectively nullify the swap then flexibility is
> achieved. A handler can then deal with the subtest_start and
> subtest_end events in its own way.
>
>Perhaps a cleaner way would be for the event coordinator to ask the
> event handler if it wants to be swapped out in the event of a
> subtest. Just an attribute on a handler that defaults to true.
>
>OTGH I don't see why the exception is necessary. There's no harm in
> storing the same object twice in the stack and it eliminates a bunch
> of special case code in the EventCoordinator.
To be specific, I picture the interface as one of:
a) subtest_start() must return the subtest handler object
(might be a new object, or just $self)
or:
b) subtest_start() must return the $invocant, $method, %args for
construction of the subtest handler object
(might be [$classname,'new', foo => 'bar'] or [$self, sub{shift}])
(Where "return" might be in some way besides return() if warranted.)
I think b is a better way to go if you want to keep more flexibility at
the framework level. It might seem like a trivial difference, but it's
really sausage or bacon. By deferring the execution, you will be able
to put things before the construction/swap, add arguments to the method
call, and other fun stuff within the framework's scope. If you go with
a, the constructor already executed and the sausage is already ground.
>That's... almost Orwellian. Strictures are flexibility!
For a long-term framework design, I think what you have seen with
e.g. 'ok or diag' vs stop-on-failure is very telling. If the execution
is ceded to the caller (sausage), you limit what features the framework
can add in the future. But, whenever the "do this" is brought back
into the scope of the framework in some composable fashion (i.e.
deferred execution), the framework can add before/after/around (or even
skip?) features later because you have that extra bit of control.
--Eric
--
software: a hypothetical exercise which happens to compile.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
