# from Michael G Schwern
# on Tuesday 25 October 2011 12:57:
>On 2011.10.25 12:29 AM, Eric Wilhelm wrote:
>> I like the sound of plan B, except for the "stores itself in"
>> combined with "swap me out".
>
>Any specific doubts?
I'm only working from intuition and my understanding of what you
described as the problem. If you try to implement a few scenarios of
special handler functionality using each design approach, that might
help clarify the issues.
It just sounds like a lot of mechanics to require/allow from the handler
objects. If the specific push/pop/swap mechanism is handled by the
event coordinator, you leave less to go wrong. I see it as mostly
a "memory management" sort of problem in that it is tedious and
error-prone for objects to ad-hoc manage holding other objects which
are not really under their authority.
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.
Mainly, this structure seems upside down -- because if the handler
object is expected to take care of storage and swap-out, it must retain
the parent and return it to be 'current' at the end.
subtest->new(...,
parent => subtest->new(...,
parent => subtest->new(...,
parent => $root
)
)
)
The trouble with doing this with a stack in the coordinator instead is
that you may need a way for a subtest to access its parent handler for
context -- but that need doesn't dictate that the subtest handler must
store the parent handler. For instance, perhaps you continually pass
the coordinator or a context in e.g. $handler->$method($coordinator)
and allow access via that with the proviso that $coordinator's
attributes must not be held in $handler. My main concern here is
avoiding memory-loop and handler swapping bugs which are likely when
various handlers start interacting.
>> have the coordinator providing the functionality which you were
>> thinking of getting from the delegator.
>
> problems are A) it constrains what an event watcher can do...
>But I don't see a solution to A.
>..., I can easily imagine a history or event logger
> that wants to record the whole test as a tree.
>
>Part of the point is to provide maximum flexibility to test module
> authors, so we're not stuck with design mistakes 10 years later,
> while still retaining a system that's easy to use if you do things as
> expected.
It seems like keeping the stack/current control in the coordinator will
help more than hurt in future flexibility. Would you rather be blocked
from making a change because somebody did something you didn't think of
in a subtest_start() and the API had granted them implicit permission
to do that (aka "total control") or grow from a more conservative
position where more of the data and flow control is managed by your
coordinator object which grants flexibility via defined interfaces?
--Eric
--
So malloc calls a timeout and starts rummaging around the free chain,
sorting things out, and merging adjacent small free blocks into larger
blocks. This takes 3 1/2 days.
--Joel Spolsky
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
