On 2011.10.25 10:54 PM, Eric Wilhelm wrote:
> 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.
All I really have is "nested formatting" and "logger that wants to see
everything". I'm not yet sure if the history will best be handled by a single
object or children.
The odd part about building a long term framework is I really don't know what
people are going to use it for.
> 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.
> 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.
The default implementation EventWatchers inherit would do that, and there'd be
a slot for it. Bets are off if you do it yourself.
> 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.
Already done. Good validation of the design that you came up with it
independently. :)
my $parent = $coordinator->give_me_my_parent($handler) is going to be
interesting to implement. Again, I think handlers are going to need IDs.
Well, events already have them so I can just turn that into a role. It'll
probably be useful later.
> My main concern here is
> avoiding memory-loop and handler swapping bugs which are likely when
> various handlers start interacting.
Yeah, that's what has me worried, too.
> 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?
That's... almost Orwellian. Strictures are flexibility!
Ok, I'm convinced. Not by the last argument, but in general. Thanks!
--
101. I am not allowed to mount a bayonet on a crew-served weapon.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
