2022/06/24/event-object as output container

From Woozle Writes Code
Jump to navigation Jump to search

originally rubberducked on Discord


Crikey. Just realized a huge problem with my "stuff everything into Event-object property string" revision scheme: that leaves parent-nodes unable to detect what has been added by child-nodes (as opposed to existing content).


Ok, well... since the old system required the caller/parent to explicitly incorporate the child's output into its own output, I should implement something similar in the Render Event...


ugh ugh ugh


So, before, I was pretty much taking advantage of the call-stack (local variables) to keep things straight. Stuffing all the values into an object means I can't do that anymore. If that's the mechanism I need, then I need to replicate it inside the object -- which seems like wasted/duplicate effort. Maybe I should just... allow OnRender functions to return a string? But then where do they get stuffed back into the Event object? Or is that even necessary? (edited)


Ok, I think the place it becomes necessary is where the event-chain transitions from general dispatch to calling the Event-class's designated method. That's why I had to eliminate the return value in the first place, because neither of the other two Event-classes needed return values (and future Event-classes might store something other than a string, so it didn't make sense to say "well, okay, they'll just all return strings even if they don't need to").


This pops up a related concern: when we go to the OnRender() chain, that is explicitly fetching values from sub-nodes and computing results from them -- but OnEvent() could still be passing the Render event down to those subnodes. By what system can I be sure to prevent duplicate rendering?


I think the original idea was that with OnRender(), I'd discontinue that explicit call-and-calculate methodology... but it seems to be necessary...


There has to be some way of flagging the fact that the Event has been dispatched, and so OnEvent() should not pass it down further. That would fix one fork of this issue.


Idea: it would/could actually be an improvement if I were to let the existence of a handler-method in a given class determine whether or not the event-object continues getting passed down the tree.

Caveat: I hope checking an object for the existence of a method isn't an expensive operation. I guess if it later turns out to be, we could also have a flag-member or something... but I bet it's less expensive than an actual method-call, and no more expensive than looking up a member-value.


There seem to be a lot of places where I've set up RenderBefore/RenderMain/RenderAfter dispatch sequences under various names, and most of them didn't even get used.


what I eventually worked out

Sometimes I think I spend way too much time refining my nomenclature.

Sometimes I think, well, maybe it wouldn't be necessary for other people, but I need those cues to help me keep things straight.

...and sometimes I think yes, actually nomenclature is important. It needs to be consistent, locally and (as much as possible) globally. Nuance is important. Brain-cell-requirements-reduction is important.


That said, I think I have this worked out. holds up 8½"x11" sheet of scrap paper with class notes and function names all over it